Makaleler
Yapay zekanın tavanı hırsınızdır: hız, yükseklik, derinlik ve genişlik olmak üzere dört boyut
Anthropic mühendislik yöneticisi Felix Rieseberg, "yapay zekaya karşı daha hırslı olmayı" hız, yükseklik, derinlik ve genişlik olmak üzere dört boyuta ayırıyor. Bu yazı onun yöntemlerini ve örneklerini derliyor, üstüne kendi uygulama notlarımı ekliyor: hedef odaklı talimatlarla Multi-AI Agents uzman ekibini yönetip çok açılı çapraz inceleme yaparak görev kalitesini yükseltmek.
· 5 dk okuma
Anthropic mühendislik yöneticisi Felix Rieseberg, How to be more ambitious: A tutorial for humans with models yazısında şunu anlatıyor: Başkalarının yapay zekayla çarpıcı sonuçlar çıkardığını gördüğünde, kendisi ve çevresindekiler hep aynı tepkiyi veriyor: "Yeterince hırslı değiliz."
Benim yorumum şu: İnsanların yapay zekayı kullanırken ulaşabildiği sınır, çoğu zaman modelde değil, kendi hırslarında ve hayal güçlerinde düğümleniyor.
Felix "hırsı" dört boyuta ayırıyor:
- Hız (Speed): Aynı işi daha kısa sürede bitirmek.
- Yükseklik (Altitude): Soyutlama seviyesini yükseltip tek bir göreve değil, nihai sonuca bakmak.
- Derinlik (Depth): İşi alanın en iyi uzmanlarının standartlarıyla, araçlarıyla ve yöntemleriyle yapmak.
- Genişlik (Range): Tek bir alanın dışına çıkıp alanlar arası çözümler aramak.
Önce sonucu söyleyeyim: Hedef odaklı talimatları net verip Multi-AI Agents uzman ekibini çok açılı iş birliği ve çapraz incelemeye yönlendirdiğinizde, görev kalitesi bir bütün olarak yükselir.
1. Hız: en temel boyut ve en az kişinin takıldığı boyut#
Aynı işi daha kısa sürede bitirmek. Felix bunun herkesçe zaten iyi bilindiğini düşündüğü için yazıda doğrudan geçiyor.
Bana göre: Hız, yapay zekanın en sezgisel değeri; ama yalnızca hızın peşinden gidersek iş birliği biçimimiz pek değişmez. Asıl farkı yaratan, sonraki üç boyut.
2. Yükseklik: "Hedefin ardındaki hedefi" sormak#
Temel soru: Sıradaki adımda gerçekten istenen sonuç ne? Hedefin ardındaki hedef ne?
Felix'in örnekleri:
- Bir Crash'i düzeltmekten, uygulamanın artık Crash vermemesini sağlamaya. Önce Claude'dan tek bir Crash'i düzeltmesini istemiş, sonra uygulamanın sıfır Crash'te kalmasını talep etmiş. Bunun sürekli otomatik çalışabilmesi için önce kendi süreçlerini değiştirmesi gerekmiş: Crash raporlarına kolay erişim sağlamak, uygulama sürümlerini Git Commit'lerle eşlemek, Claude'un Windows, macOS ve Linux makinelerini kullanarak düzeltmeleri yeniden üretip doğrulayabilmesini sağlamak.
- Üç aşamada yükselen çeyreklik iş değerlendirmesi (QBR):
- Mümkün olduğunca ham veri kullanarak bu çeyrekte neyin değiştiğini, nedenini ve bundan sonra ne yapılması gerektiğini anlat.
- En acil 3 kararı bul, her biri için lehte ve aleyhte argümanları yaz.
- Sorunları çeyreklik sunumdan daha erken fark eden alternatif bir mekanizma tasarla, geçmiş verilerle test et, sonra mevcut süreçle yan yana bir çeyrek boyunca çalıştır.
Sınırı da hatırlatıyor: 2026'da "Claude, git bana para kazan" gibi bulanık hedefler henüz işe yaramıyor; ama modellerin ele alabileceği soyutlama seviyesinin giderek yükseleceğini bekliyor.
3. Derinlik: alanın en iyi uzmanlarının çıtasına göre çalışmak#
Felix'in yöntemi:
- Sektörün gerçekten kullandığı araçları kullanın. Model çoğu zaman yalnızca kelimeleri değiştirir, yöntemi değiştirmez; bir Markdown tablosu atıp işi geçiştirir. Veritabanı, istatistiksel model gibi gerçek analiz araçlarını kullanmakta ısrar edin.
- Makul görünmeyen bir hedef koyun ve modele bunun çözülebilir olduğunu söyleyin. Örneği: Bir sitenin yüklenme süresini 10 saniyeden 5 saniyeye indirdikten sonra 200 milisaniye istemiş. Model geri adım attığında, bu hedefin ulaşılabilir olduğunda ısrar edin.
- Kendi inandığınız varsayımlara meydan okuyun. Modele ham veriyi verip karşıt bir bakışla sınatın. Örneğin: "Kullanıcı kaybının onboarding kaynaklı olduğunu düşünüyoruz; bu sonucu ham veriden yeniden üretmeyi dene."
- Yeni bilgi üretin. Log'lardan bir simülasyon kurun, henüz bilmediğiniz en erken kayıp sinyalini bulun, sonra görmediği verilerle doğrulayın.
- Dış hakem (Outside Judge) bulun. Modelin kendi işini kendisinin notlandırmasına izin vermeyin. En iyisi, modelin doğrudan çalıştırıp anında geri bildirim alabileceği bir araç bağlamak.
Prompt yaklaşımı şu: İstenen "daha büyük bir sürüm" değil, "daha derin bir sürüm". Modelden, en iyi profesyonellerin fazladan neler yapacağını, en ham verinin nerede olduğunu, hangi yöntem ve araçların kullanılacağını ve modelin ya da sizin yargınızın dışında sonucun doğru olduğunu neyin kanıtlayabileceğini söylemesini isteyin.
4. Genişlik: isim yerine fiil, bir uzman ekibi kurmak#
- İsim yerine fiil. Bu fikri Felix, The Art of Innovation kitabından alıyor. QBR "bir sunum" olmaktan çok, "30 dakika içinde meşgul insanların neden sonuç ilişkisini anlayıp belirsizlik altında karar vermesini sağlamak"tır. Hedefi fiille tanımlayınca hangi alanların yetkinliğine ihtiyaç olduğu görülür.
- Bir ekip kurun. İyi bir sunum için analist, gazeteci ve editör bulun; sahnede sunacaksanız buna hareket ve ses tasarımcısı ekleyin. Karşıt bir inceleme için açığa satış kuruluşlarındaki araştırmacıları ve adli muhasebecileri bulun.
- Anlamsız rol yapmayın. Modele "açığa satış kuruluşunun üslubuyla yaz" demeyin; açığa satış kuruluşlarının bir bölümü araştırırken kullandığı yöntemi gerçekten uygulamasını isteyin. Yalnızca üslubu değiştirmek sonucu daha iyi yapmaz.
Ön koşul: Modelin yazılım kurabileceği bir bilgisayarı olmalı ve MCP bağlayıcıları gibi yollarla ilgili verilere erişebilmeli.
5. Uygulama notlarım: "veri aktarımından" "amaca ulaşmaya"#
Aşağıdakiler, yazılım mimarisi ve mühendislik pratiğiyle birleştirdiğim uzantılar; orijinal yazının içeriği değil.
1. Jobs to be Done ve amaç odaklılık (Intent-Based)#
- "Ne yapılacak" diye değil, "neye ulaşılacak" diye sorun. Tasarım,
generate_deck_pdf() gibi pasif bir veri aktarım hattında kalmamalı; resolve_leadership_uncertainty_and_commit_budget() gibi bir durum geçişi amacına yükselmeli.
- Gerçek kayıp fonksiyonunu tanımlayın. Yalnızca çıktı isterseniz model kusursuz görünen boş laflar üretir; karar belirsizliğini çözmesini isterseniz model ve Sub-agent'lar mantık açıklarını ve risk sınırlarını kendiliğinden doldurur.
2. Keşifte yay, kabulde daralt#
- Keşif sırasında önce olasılıkları bulmak için yayın, sonra daraltın.
- Kabul sırasında artık yaymayın. "Bu iş başka nasıl yapılabilir?" gibi sınırsız sorulardan kaçının; yalnızca genel geçer cevaplar getirir.
- Hedef kapsamını, kısıtları ve nesnel doğrulama araçlarını (belirli test betikleri, iş metriği eşikleri) açıkça yazın; böylece Multi-Agent ekibi odaklı bir çerçevede stres testi yapıp yüksek kaliteli sonuç teslim eder.
Çıkarımlar#
- Hedef odaklılık: İsim yerine fiil kullanın. Yalnızca iş geçiştirmek için üretilmiş çıktılar değil, sorunu çözen sonuçlar teslim edin.
- Keşif ve daraltma: Keşifte olasılıkları bulmak için yayın, kabulde sıkı biçimde daraltıp sınırları doğrulayın.
- Soyut odak: Temel sorudan yola çıkıp görev akışının tamamını yeniden kurun.
- Uzman derinliği: Uzmanın yalnızca üslubunu taklit etmeyin; modeli, en iyi uzmanların araç ve yöntemleriyle sorunu çözmeye zorlayın.
Orijinal yazı: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)