AI'ın Computer Use özelliği, yapılandırılmış API'lerden 45 kat daha pahalı

 (reflex.dev)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Aynı yönetici paneli görevinde vision agent, ekran görüntüleri ve tıklamalarla UI'ı kullandı; API agent ise aynı uygulama işleyicilerini yapılandırılmış yanıtlarla çağırdı ve maliyet farkında değişken olarak yalnızca arayüz bırakıldı
  • Temel promptta API agent görevi 8 çağrıda tamamladı; vision agent ise görünür alanın altında kalan bekleyen 3 incelemeyi kaçırarak 4 incelemeden yalnızca 1'ini onayladı
  • 14 adımlık bir UI walkthrough eklendiğinde vision agent da görevi tamamladı, ancak çalıştırma yaklaşık 14 dakika ve yaklaşık 500 bin giriş token'ı gerektirdi; bu kadar ayrıntılı yönlendirme de ayrıca bir mühendislik maliyeti oluşturdu
  • Genel sonuçlarda Sonnet için vision yolu ortalama 53 adım, 1003 saniye ve 550.976 giriş token'ı kullandı; API yolu ise 8 çağrı, 19,7 saniye ve 12.151 giriş token'ı ile tamamlandı; maliyet ve süre değişkenliği de çok daha düşüktü
  • Maliyet farkı model performansından değil, arayüz yapısından kaynaklandı; Reflex 0.9 gibi araçlar olay işleyicilerinden otomatik HTTP endpoint'leri ürettiğinde, doğrudan geliştirilen iç araçlarda yapılandırılmış API yolunun maliyet hesabı daha avantajlı hale geliyor

Benchmark amacı ve deney düzeni

  • Aynı yönetici paneli, vision agent ve yapılandırılmış API yaklaşımıyla kontrol ettirilerek tarayıcı kullanımı / bilgisayar kullanımı tarzındaki maliyet ölçüldü
  • API sunmayan web uygulamalarını AI agent'ların kontrol etmesi gerektiğinde, vision agent varsayılan seçenek haline gelmeye yatkın oluyor
  • Takımların 20'den fazla iç araca sahip olduğu ortamlarda, her uygulama için MCP ya da REST yüzeyi yazmak ayrı bir mühendislik projesine dönüştüğü için birçok takım vision agent'ı seçiyor
  • Test uygulaması; müşteri, sipariş ve inceleme yöneten bir yönetici paneli ve model olarak react-admin Posters Galore demo kullanıldı
  • İki agent da aynı çalışan uygulamayı, aynı Claude Sonnet modelini, aynı sabit veri kümesini ve aynı görevi kullandı; yalnızca arayüz değişkendi
  • Görev, adı “Smith” olan müşteriler arasında en çok sipariş veren kişiyi bulmak, ardından bu müşterinin en son bekleyen siparişini tespit etmek, bekleyen tüm incelemeleri onaylamak ve siparişi teslim edildi olarak işaretlemekti
  • Bu görev üç kaynağa dokunuyor; filtreleme, sayfalama, varlıklar arası sorgulama, okuma ve yazma içeriyor; bu da tipik iç araç işlerine benziyor

İki yürütme yolu

  • Yol A: Vision agent

    • Claude Sonnet, browser-use 0.12'yi vision modunda kullanarak UI'ı ekran görüntüleri ve tıklamalarla kontrol etti

  • Yol B: API agent

    • Claude Sonnet, araç kullanımı yaklaşımıyla uygulamanın HTTP endpoint'lerini doğrudan çağırdı
    • Her araç, uygulama state'inin bir veya daha fazla olay işleyicisine eşlendi ve buton tıklamasının çağırdığıyla aynı fonksiyonlar kullanıldı
    • Agent, render edilmiş sayfa yerine yapılandırılmış yanıtlar aldı

Vision agent'ın temel promptla neden başarısız olduğu

  • İki agent da aynı altı cümlelik görevle çalıştırıldı
  • API agent görevi 8 çağrıda tamamladı
    • Beklemede durumuna göre filtrelenmiş müşteri incelemelerini listeledi
    • Her incelemeyi onayladı
    • Siparişi teslim edildi olarak işaretledi
  • Her iki agent da aynı uygulama mantığını çağırdı, ancak API agent render edilmiş sayfayı görmek yerine yapılandırılmış yanıtları doğrudan okudu
  • Vision agent, aynı promptla bekleyen 4 incelemeden yalnızca 1'ini bulup onayladı ve sonraki adıma geçti
  • Kalan 3 inceleme, inceleme sayfasındaki görünür alanın altındaydı ve agent'a kaydırma yapması gerektiğini söyleyen bir sinyal yoktu
  • Bu başarısızlık modelin akıl yürütmesinden değil, render edilmiş sayfanın her şeyi göstermediğine dair sinyal verememesinden kaynaklandı
  • API agent, UI'ın çağırdığı işleyicilerin aynısını çağırıyor; ancak yanıtta yalnızca o anda render edilen satırlar değil, işleyicinin döndürdüğü tüm sonuç kümesi yer alıyor
  • API agent, sayfalama kontrolünü piksellerden yorumlamıyor; onun yerine “her sayfada 50 öğe gösterilen 4 sayfanın 1. sayfası” gibi bilgileri doğrudan okuyor

14 adımlık UI yönlendirmesi eklendiğinde sonuçlar

  • Adil bir karşılaştırma için vision prompt, açık bir UI walkthrough olarak yeniden yazıldı
  • Kenar çubuğu öğeleri, sekmeler, form alanları gibi agent'ın her adımda etkileşime girmesi gereken UI öğeleri isimleriyle belirtildi
  • Agent'ın daha önce kendi başına bulamadığı gezinme süreci, 14 numaralı talimat halinde yazıldı
  • Bu yönlendirme verildiğinde vision agent görevi tamamladı
  • Ancak çalıştırma 14 dakika sürdü ve yaklaşık 500 bin giriş token'ı tüketti
  • Her numaralı talimat, token sayısında görünmese de gerçek bir mühendislik maliyetine işaret ediyor
  • İç araçlarda vision agent kullanıma alınacaksa ya bu düzeyde ayrıntılı promptlar yazmak ya da agent'ın işi sessizce eksik bırakma riskini kabul etmek gerekiyor

Çalıştırma biçimi ve değişkenlik

  • API yolu 5 kez, vision yolu 3 kez çalıştırıldı
  • Vision yolunun bir çalıştırması 14 ila 22 dakika sürdüğü ve 400 bin ila 750 bin token tükettiği için 3 çalıştırmayla sınırlandı
  • Vision yolunda çalıştırmalar arası varyans yüksekti
    • 3 çalıştırmada geçen gerçek süre 749 saniyeden 1257 saniyeye kadar değişti
    • Giriş token'ları 407 binden 751 bine kadar değişti
    • En kısa çalıştırma 43 çevrim, en uzun çalıştırma 68 çevrim sürdü
  • Ekran görüntüsü-akıl yürütme-tıklama döngüsünde yeterince rastlantısallık olduğu için tek bir çalıştırmadan temsilî maliyeti tahmin etmek zor
  • API yolunda böyle bir değişkenlik yoktu
    • Sonnet, 5 çalıştırmanın tamamında aynı şekilde 8 araç çağrısı kullandı
    • Giriş token sayısı 5 çalıştırmanın tamamında yalnızca ±27 aralığında değişti
    • Yapılandırılmış yanıtlar, agent'ın yoldan sapmasına neden olmadığından aynı sırayla aynı işleyiciler çağrıldı

Genel sonuçlar

Metrik Vision agent (Sonnet) API (Sonnet) API (Haiku)
Adım / çağrı 53 ± 13 8 ± 0 8 ± 0
Gerçek süre 1003 sn ± 254 sn, yaklaşık 17 dk 19,7 sn ± 2,8 sn 7,7 sn ± 0,5 sn
Giriş token'ı 550.976 ± 178.849 12.151 ± 27 9.478 ± 809
Çıkış token'ı 37.962 ± 10.850 934 ± 41 819 ± 52
  • Rakamlar ortalama ± örnek standart sapma (n−1) olarak verildi; API yolu için n=5, vision yolu için n=3
  • Tüm çalıştırma ayrıntıları depoda görülebilir
  • Haiku, vision yolunu tamamlayamadı
  • Başarısızlık, browser-use 0.12'nin yapılandırılmış çıktı şemasıyla sınırlıydı; Haiku bunu hem vision modunda hem de yalnızca metin modunda kararlı biçimde üretemedi
  • API yolunda Haiku, 8 saniyenin altında ve 10 bin giriş token'ının altında tamamladı; test edilen yapılandırmalar içinde en ucuz olanı buydu

Yapısal maliyet farkı

  • Maliyet farkı doğrudan mimariden geliyor
  • Davranabilmek için görmek zorunda olan bir agent, model ne kadar iyileşirse iyileşsin görme maliyetini her zaman ödemek zorunda
  • Daha iyi vision modelleri ekran görüntüsü başına hata oranını düşürebilir, ancak ilgili veriye ulaşmak için gereken ekran görüntüsü sayısını azaltmaz
  • Her render bir ekran görüntüsüdür ve ekran görüntüleri binlerce giriş token'ına dönüşür
  • İki agent da aynı uygulama mantığından geçiyor
    • İkisi de UI ile aynı şekilde filtreleme, sayfalama ve güncelleme yapıyor
    • Fark, her adımda neyi okuduklarında ortaya çıkıyor
  • Vision agent pikselleri okuyor ve tüm ara durumları render ederek yorumlamak zorunda kalıyor
  • API agent ise aynı işleyicilerden gelen yapılandırılmış yanıtları okuyor; bu yanıtlarda UI'ın göstermeyi amaçladığı veri zaten bulunuyor
  • Daha iyi modeller adım başına maliyeti düşürebilir, ancak adım sayısı arayüz tarafından belirlendiği için azalmaz

API mühendislik maliyeti düştüğünde değişen karar dengesi

  • Benchmark, Reflex 0.9 sayesinde düşük maliyetle yapılabildi
  • Reflex 0.9, Reflex uygulamalarındaki olay işleyicilerinden otomatik HTTP endpoint'leri üreten bir eklenti içeriyor
  • Yapısal argüman Reflex'e bağlı değil, ancak Reflex API yolunu ayrı bir kod tabanı olmadan çalıştırılabilir hale getiriyor
  • Asıl mesele, API yüzeyinin mühendislik maliyetinin sıfıra yaklaşmasıyla neyin mümkün hale geldiği
  • Vision agent hâlâ doğrudan kontrol edilmeyen uygulamalar için uygun
    • Üçüncü taraf SaaS ürünleri
    • Legacy sistemler
    • Değiştirilemeyen uygulamalar
  • Doğrudan geliştirilen iç araçlarda ise maliyet hesabı tersine dönüyor

Deney kapsamı ve dikkat noktaları

  • Vision sonuçları browser-use 0.12'nin vision moduyla sınırlı; diğer vision agent'lar farklı davranabilir
  • Yol B çalıştırıcısı, otomatik üretilen endpoint'leri yaklaşık 30 satırlık küçük bir REST araç yüzeyine dönüştürdü
  • Agent bunu list_customers, update_order gibi araçlar olarak gördü
  • Veri kümesi sabit ve küçük
    • 900 müşteri
    • 600 sipariş
    • 324 inceleme
  • Prodüksiyon ölçeğindeki verilerde davranış ölçülmedi
  • Vision agent, LangChain'in ChatAnthropic arayüzü üzerinden çalıştırıldı
  • API agent, Anthropic SDK doğrudan kullanılarak çalıştırıldı
  • Raporlanan token sayıları önbelleğe alınmamış giriş token'larıdır

Yeniden üretim materyalleri

  • Depoda seed veri üretimi, yamalanmış react-admin demosu, iki agent script'i ve ham sonuçlar yer alıyor

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • Ajanların web sitelerinde gezinmesini pahalı hale getirmenin yolu burada gizli: fare hareket ederken ekrandaki öğeleri oynat, UI yalnızca doğal fare hareketi zorlandığında çalışsın, her ziyarette JS içinde düğme etiketlerini rastgele adlarla değiştir ve gizli ek işleri görmek için ekranın en altına kadar kaydırmayı zorunlu kıl
    Bir dakika, bu bildiğimiz kurumsal SaaS uygulaması gibi

    • Eskiden buna inanmayan insanların, yapay zeka yüzünden bir anda iyi yazılım mühendisliği pratiklerine, özellikle de spesifikasyon yazımına sarılması tuhaf
      İnsanlar için bunları yapmaya niyetleri yoktu ama yapay zeka ihtiyaç duyunca herkesin koşması hem ilginç hem de biraz moral bozucu. Sonuçta bunu soyut bir gelecekteki biri için değil, kendilerine fayda sağladığını hissettikleri için yalnızca yapay zeka adına yapıyor gibiler
    • Mesele bunu insanların yapmak isteyeceği bir şeye dönüştürmek. [0]'daki gibi etkileşimli öğeleri hareket ettirebilir, bağlama göre ortamla etkileşime girmesini sağlayabilirsiniz
      [0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
    • Demek ki başından beri ihtiyacımız olan teknoloji ASP WebForms imiş
    • Bir zamanlar bir masaüstü uygulamasının tüm grid kontrol içeriğini Windows erişilebilirlik API'sinden bilerek gizlediği, erişilebilirlik API üzerinden onay kutusu ya da radyo düğmesi seçimini de yansıtmayacak şekilde engellediği ve veri dışa aktarma özelliklerinin tamamını CAPTCHA ile koruduğu bir projede çalışmıştım
      Bu, üretken yapay zeka çağından önceydi ama uygulamayı çalıştırıp veriyi dışa aktarmak için OCR, simüle edilmiş kullanıcı girdisi ve yazdırma yakalamayı birleştirmek zorunda kalmıştık. Geliştiriciler ekran görüntüsünü engelleyen Windows DRM API'lerini ya da PostScript dosyalarından metnin minimal biçimlendirmeyle kolayca çıkarılabildiğini bilselerdi ne yaparlardı bilmiyorum
      İronik olan şu ki, bunu değiştirmeden önceki süreç, ucuz yurtdışı iş gücüne sistemdeki tüm verilere salt okunur uzaktan erişim vermekti; bu da güvenilir bir sağlayıcının yerel aracında, onaylı çalışanların ağ erişimi olmadan işi otomatikleştirmesinden çok daha büyük bir güvenlik riskiydi

  • Tam olarak bu sorunu çözen bir şey geliştiriyorum[1]
    Landing page'de henüz öne çıkarmadım ama özünde, ajana uygulamanın yüzeyini keşfetmesi için küçük bir araç seti ve özellikle erişilebilirlikle ilgili genel macOS özellik API'lerini veriyor
    Ajan uygulamayı keşfettikten sonra tekrarlanabilir iş akışları yazabiliyor ve daha sonra bunları CLI'den invoke chrome pinTab gibi çalıştırabiliyorsunuz
    Erişilebilirliği kullanma nedenimiz, bunun uygulamalar için iyi bir DOM olması. Her uygulama bunu kusursuz uygulamıyor ama yeterince çoğu uyguluyor ve bu da onu çok kullanışlı kılıyor
    [1] https://getinvoke.com - mevcut landing page içerik üreticilerine yönelik, bu kullanım senaryosunu henüz işlemiyor

    • Ajanlar sayesinde iyi erişilebilirlik (a11y) sağlanacaksa buna varım. Söylene söylene de olsa kabul ederim
    • macOS'ta bu alana ilginiz varsa, sistemle gelen Accessibility Inspector.app'ı açıp uygulamalar ve tarayıcılarla doğrudan oynamanızı şiddetle tavsiye ederim
      Yeşil hücrelerin bir LLM'e ekranın yalnızca belirli kısımlarını okuması ya da OCR kullanması için nasıl yol gösterebildiğini, erişilebilirlik motorunda zaten ne kadar çok metnin hazır bulunduğunu ve bunun yalnızca MCP'ye değil, iş akışının erişilebilirlik katmanını tarayan script'leri doğrudan üretip çalıştıran kod üreticilerine de kapı açtığını görebilirsiniz
      Burasının çok verimli bir alan olduğunu düşünüyorum. Büyük araştırma laboratuvarları, birden çok platform ve rastgele iş akışlarında çalışan yaklaşımlar kullanmak zorunda; tam ekran görsel yaklaşım en düşük ortak payda. Platforma özgü yaklaşımlar ise gerçekten ilginç ve açık bir alan
    • Herkesin aynı bilgisayar kullanım görevlerini tekrar tekrar yapıp token harcaması yerine, iş akışı paylaşımı için iyi bir çözüm
      Yine de parola gibi kullanıcı bilgilerini dışarı çıkaran iş akışlarının paylaşılmamasını mutlaka garanti etmek gerekir gibi görünüyor
    • İlginç. Ben de benzer şekilde başlayan bir şey yaptım; çok daha az olgun ve epey farklı ama o da erişilebilirlik UI öğeleri kullanıyor
      Büyük sorun, çok fazla uygulamanın bu öğeleri ortaya çıkarma işini berbat yapması. Benim yaklaşımım, UIAccess ya da bir vision modelin tek geçişiyle UI şablonları oluşturmaktı: https://github.com/willwade/app-automate?tab=readme-ov-file#...
      Buna yönelik reddit karşı argümanı, pratik deneyimin neredeyse tersini gösterdiği yönünde. UIA belgelerde tek tip görünse de WPF, WinForms ve Win32 farklı kontrol kalıpları açığa çıkarıyor ve sonuçta araç takımı başına ayrı handler'lar yazıyorsunuz. Qt'de bir şeylerin görünmesi için QAccessible'ın derlenmiş ve erişilebilirlik eklentisinin çalışma anında yüklenmiş olması gerekiyor; dağıtılan ikili dosyalarda bu neredeyse hiç olmuyor. Electron, Windows'ta da macOS'taki kadar opak, çünkü yine aynı Chromium tuvale çizim yapıyor. Asıl ayrım işletim sistemine karşı işletim sistemi değil, yerel araç takımı ile geri kalan her şey arasında

  • Her uygulama için MCP ya da REST yüzeyi yazmanın ayrı bir mühendislik projesi olduğu iddiası, backend frontend'den yeterince ayrılmış ve sunucu tarafı işlemleri dikkatli, genel amaçlı şekilde tasarlanmış olsaydı zorunlu olarak doğru olmazdı

  • Bir vision ajanına UI'yi “haritalatıp”, sonra bunu başka ajanlara daha API benzeri bir arayüz kümesi olarak sunmanın mümkün olup olmadığını merak ediyorum
    Şu anki anlayışıma göre vision ajanı, hem “sonraki sayfa”nın daha fazla sonuç gösterdiğini hem de en başta daha fazla sonuç getirmesi gerektiğini anlamak zorunda
    Eğer bir ajan, test ortamı benzeri bir yerde yalnızca UI'yi keşfedip çeşitli UI öğeleri ve davranışları hakkında bir miktar yapılandırılmış açıklama üretse ve ikinci ajan da o açıklamayı alsa, acaba UI keşfi ile görevi aynı anda yapan ajandan daha iyi performans gösterir mi
    Örneğin “tüm incelemeleri getir”, her sayfaya gidip her inceleme özetindeki “tam incelemeyi görüntüle”ye tıklamayı gerektiriyor diye tanımlanabilir; “her sayfaya git” de, inceleme sekmesinin varsayılanı olan 1. sayfadan başlayıp “ileri” düğmesi kaybolana kadar basmak olarak tanımlanabilir
    Böylece ikinci ajan bu tekniğe zaten sahip olur ve gezinme yöntemini düşünmeye daha az enerji harcar; birinci ajan ise test ortamında hata yapma korkusu olmadan UI'yi yalnızca bir kez keşfeder. Yazıyı tamamen yanlış anlamış olabilirim ama yine de ilginç

    • Benim de ilk aklıma gelen buydu. Günümüz web geliştirmesi büyük ölçüde kod üretimine dayanıyor, sonra bunun üstüne obfuscation ve sıkıştırma ekleniyor, ardından istemci tarafı JavaScript her şeyi yeniden kuruyor
      Sonuçta aşılması gereken şey karmaşık HTML/CSS/JavaScript oluyor. İyi ya da kötü, 5~10MiB boyutunda bir web uygulaması artık nadir değil
      Tarayıcı motorunun yaptığını fiilen tersine çevirerek “aşağıdan yukarı” gitmektense, insanlar gibi görsel sunuma bakıp “yukarıdan aşağı” yaklaşmak daha kolay görünüyor
    • Sanırım doğru. Ajanların bizim yaptığımız gibi web sitelerinin nasıl çalıştığını öğrenmesini sağlayabilir ve o modeli basit bir API olarak sunabilirsiniz
      Gezinme için yine biraz vision işi kalır ama bu, düşünmeyi gerektirmeyen basit bir vision görevi olur
    • Bir vision ajanından “haritalama” istemenin zor olduğunu düşünüyorum. Çoğu vision model, görüntü→metin yaparken bir seferde görüntünün yalnızca bir bölümüne odaklanıyor
      görüntü→görüntü ise tüm görüntüyü kullanıyor

  • Varsayımı tam anlayamadım. Eğer bu iç uygulamaysa neden bilgisayar kullanımına başvuruyorsunuz da ajanın CLI ya da MCP oluşturmasına izin vermiyorsunuz, anlamıyorum
    Elbette bilgisayar kullanımı daha kötü. Bu son çare olmalı. Sahip olduğum bir DB'deki durumu işlerken bunu kullanmamalıyım
    Asıl etkileyici olan, yalnızca 50 kat kadar kötü olması

  • Buna tamamen katılıyorum. Yakın zamanda yapay zeka destekli görsel araçlar geliştirirken iki yaklaşımı da denedim ve genel amaçlı “ajan tarzı” tarayıcı kullanımının gecikme ve maliyeti, bugün gerçek zamanlı tüketici uygulamaları için ölümcül
    Yapılandırılmış API'ler, hatta katı JSON şeması kullanan LLM çağrı zincirleri bile sadece 40 kat daha ucuz olmakla kalmıyor, gerçekten kararlı bir ürün çıkarabilmek için belirleyici oluyor. Bilgisayar kullanımı havalı bir demo; ama sunucu faturasını ödeyen şey yapılandırılmış API'ler

    • “Ajan tarzı mühendislik”, token sağlayıcılarının gelirini artırmaya yönelik bir modadan ibaretti
      LLM'lerin bir iş için iyi olduğunu düşünüyorsanız, o amaca uygun, iyi tanımlanmış ve son derece deterministik middleware'i Openrouter üstünde kurun

  • Yapılandırılmış API'ler gerçek düşünme gerektiriyor; ama bugünlerde düşünmek pek makbul sayılmıyor

  • Birkaç ay önce kubectl'den ilham alarak GUI uygulamalarını kontrol etmek için desktopctl CLI geliştirdim
    Mac'te OCR ile Accessibility API'yi birleştirip UI'yi Markdown olarak temsil ediyor ve fare ile klavye eylemlerini açığa çıkarıyor
    Temel fikir, “hızlı” algılama döngüsünü tamamen yerelde UI tokenizasyonu ve değişiklik tespiti için GPU optimize etmek; “yavaş” kontrol döngüsünün ise LLM gidiş gelişleri gerektirmesi ve CLI çıktısında token açısından verimli bir Markdown arayüzü kullanması
    Kontroller için görece kararlı tanımlayıcılar kullanıldığından, ajanlar desktopctl pointer click --id btn_save gibi genel eylemleri script'leyebiliyor ve UI tokenizasyon döngüsüne ihtiyaç duymuyor
    https://github.com/yaroshevych/desktopctl/tree/main

    • API'lerle karşılaştırınca insanlara yönelik arayüzler yavaş ve dağınık, ama yine de arkalarında epey bilim varmış, bunu öğrendim
      İyi uygulamalar bilgiyi iyi ortaya koyuyor ve tıklama, yazma vb. için optimize ediliyor
      En iyi GUI'ler kas hafızasını iyi kullanır; bu yüzden CLI ile script'lenmeye mükemmel adaydır. Örneğin “Notes uygulamasını aç, Cmd+F'ye bas, arama sorgusunu gir, sonuç listesini oku” gibi basit bir dizi, bir yapay zeka ajanının çağıracağı tek bir Bash komutu olabilir

  • “Bilgisayar kullanımı” kavramının tamamına hep kuşkuyla bakmışımdır. Bu, birini işe alıp eve sokmaya, yatakta uyumasına, tuvaleti kullanmasına, buzdolabındaki yiyecekleri yemesine, TV izlemesine izin vermeye ve kasanın şifresinin de burada olduğunu söylemeye benziyor
    Üstelik işe aldığınız o biri de maymun

    • Delirdiğimi sanıyorum. Bir yazılımın başka bir yazılıma sorgu gönderip komut verebileceği yollar oluşturmak yerine, yapay zekanın fareyle ortalıkta gezinip rastgele şeylere tıklamasının gerçekten doğru yaklaşım olmasına şaşırıyorum
    • Adil olmak gerekirse, benim yapmak istemediğim maymun işi görevleri o maymunun yapmasını istiyorum

  • Şu anda Claude Code ya da başka yapay zeka ajanlarını engelleyen web siteleri kaybedilmiş bir savaş veriyor
    Bilgisayar kullanımı henüz erken aşamada ve yaygınlaşmasını engelleyen şey gerekli token sayısı gibi görünüyor. Bir ajan doğru komutu bulana kadar 10 CLI komutunu boşa denese pek umursamıyoruz
    Ama tarayıcı kullanımı ya da bilgisayar kullanımı gibi görsel ajanlarda, sonunda doğru yere ulaşsa bile tek bir düğmeye tıklamak için 20 dakika bekleyecek sabrımız yok. Token'lar daha ucuz ve daha hızlı olursa, UI arayüzlerini CLI kadar doğal kullanabilen modellerin ortaya çıkması çok olası

    • Token'ların ucuzlayacağını sanmıyorum. Girişim sermayesiyle sübvanse edilen token'lar kullanıcı tabanı oluşturmak içindi; sonunda büyümeden kârlılığa geçildiğinde token fiyatları artacak gibi görünüyor
    • Bir de ölümcül üçlü koşul var. Şu an tüm ajanlar için geçerli ama, bütün AI sağlayıcıları tarayıcıda AI'a kişisel verilere erişim vermek konusunda güçlü uyarılar ekliyor
    • Gerçek LLM sağlayıcılarını kimse durduramaz. İçeriği taramak için gizlenmiş istekler kullanıyorlar, bazen de ev tipi proxy kullanıyorlar
    • %100 etkili olması gerekmiyor. İnsanları hesaplarının askıya alınacağından korkutup denemekten vazgeçirecek kadar ürkütmesi yeterli
    • Yaygınlaşmayı engelleyen şey token sayısından çok devasa maliyet, giderek artan elektrik israfı ve kullanılabilir suyun israfı