Agent’ların daha fazla prompt’a değil, kontrol akışına ihtiyacı var

• Karmaşık görevleri güvenilir biçimde ele alan agent’lar, daha gelişmiş prompt zincirlerine değil, yazılıma kodlanmış deterministik kontrol akışına ihtiyaç duyar
• Prompt’larda MANDATORY veya DO NOT SKIP gibi ifadelere güveniyorsanız, prompting’in sınırına ulaşmışsınız demektir
• Cümlelerin öneri gibi çalıştığı ve fonksiyonların halüsinasyon görüp yine de “Success” döndüren bir programlama dili hayal ederseniz, karmaşıklık arttıkça muhakeme imkânsızlaşır ve güvenilirlik çöker
• Yazılım; kütüphaneler, modüller ve fonksiyonlardan oluşan özyinelemeli bileşimsellik sayesinde ölçeklenir ve öngörülebilir davranış sağladığı için yerel muhakemeyi mümkün kılar
• Prompt zincirleri dar görevlerde faydalıdır, ancak deterministik değildir, spesifikasyonu zayıftır ve doğrulanması zordur; bu nedenle aynı niteliklere sahip değildir

Agent güvenilirliği için gerekli yapı

• Güvenilirlik sağlamak için mantığı doğal dil açıklamalarından çıkarıp runtime’a taşımak gerekir
• Gerekli yapı, LLM’i tüm sistemin kendisi değil tek bir bileşeni olarak ele alan deterministik bir scaffold’dur
• Bu scaffold, açık durum geçişlerini ve doğrulama kontrol noktalarını içermelidir
• Yalnızca deterministik orkestrasyon yeterli değildir; sessizce başarısız olabilen sistemlerde agresif hata tespiti gerekir
• Programatik doğrulama olmadan seçenekler üçe düşer

  • Gözetmen (Babysitter)

    • Bir insanın döngünün içinde kalıp hataları yayılmadan önce yakalaması gerekir

  • Denetçi (Auditor)

    • Çalışma tamamlandıktan sonra tüm sonucun kapsamlı biçimde doğrulanması gerekir

  • Dua (Prayer)

    • Sonucu genel hissiyata göre kabul etme yaklaşımına bel bağlanır

[GN⁺]

Hacker News yorumları

• %1000 katılıyorum. Anthropic’in durmadan tekrarladığı “gelecekteki model performansına göre inşa edin, yakında daha iyi olacak” davulunu giderek daha zor inanılır buluyorum
  Tarayıcı oturumunda 200 gereksinim Markdown dosyasını tarayan bir QA ajanı yaptım ve ekip verimliliğini ciddi biçimde artıran iyi bir sistemdi. Ama “bu dizindeki gereksinim dosyalarına bak ve her dosya için uygulamanın bu gereksinimleri karşılayıp karşılamadığını kontrol edecek yapılacaklar maddeleri oluştur” gibi üst düzey kontrol akışını modele bıraktığınızda yaklaşık 30 dosyadan sonra dağılıyordu
  Dosyaları atlıyor, bazı dosya gruplarını üçer kez test edip 3 dakikalık işi 10 dakikaya çıkarıyor ya da tek bir dosyadaki hata yüzünden önceki 4 dosyayı sebepsiz yere tekrar test ediyordu. Opus 4.6 ve GPT 5.4’te, ayrıca yüzeysel baktığım Opus 4.7 ve GPT 5.5’te de workflow orkestrasyonu yeteneği tutarlı değildi
  Sonunda modelin etrafına çok basit bir deterministik harness kurdum; her test vakası için modeli çağırıp testi yaptırdım, sonucu bir diziye kaydettim ve dosyaya yazdırdım. Sistem güvenilirliği ezici biçimde arttı. Ama Cursor Cloud Agents ya da Anthropic gibi yönetilen ajan platformları “her şeyi ajan çalıştırmalı” fikrine fazla takmış durumda; doğru noktalara biraz determinizm eklemenin değerini göremiyor gibiler

  • Eskiden insanları sadece prompt kullanan workflow’lara itmelerinin nedeninin token maliyetinden para kazanmaları ama kullanıcıların kurduğu scaffolding’den para kazanamamaları olduğunu sanıyordum. Şimdi ise daha çok, birilerinin bu scaffolding’i tasarlayıp uygulaması gerekeceği fikrinden korkuyor gibiler
    Çünkü bu, teknolojinin bütün insanları ya da tüm workflow’ları, projeleri bütünüyle ikame edeceği iddialarının havasını indiriyor. Bunun verimliliği ciddi biçimde artırıp geliştirici işe alım piyasası ve ücretler üzerinde felaket etkiler yaratabileceğini düşünüyorum, ama bu özel teknolojinin mevcut sürümünün onların söylediği seviyeye ulaşacağına inanmıyorum. Eğer bunu “insan geliştirme ekiplerinin angaryasının büyük kısmını azaltan çok kullanışlı bir araç” diye konumlandırsalardı, geliştiriciler isterdi ama yöneticiler daha az isterdi ve yatırımcılar da rahat bırakmazdı
    Ayrıca ayrıntılı ve sıkı şekilde kontrol edilen adımlar, test otomasyonu ya da CSI fanfic’inden 5 cildi göz açıp kapayıncaya kadar yazan dev modellerden ziyade, daha küçük, daha ucuz ve daha uzmanlaşmış modeller eklemeye çok daha elverişli
  • Bu, modelleri değerlendirme biçimimiz olan benchmark yaklaşımından kaynaklanıyor olabilir
    Bazı benchmark’larda tek bir probleme birden fazla deneme hakkı verilip, başarısızlık oranı göz ardı edilerek başarılı sonuç bir kez bile çıksa sadece o sonuç kabul edilmiyor mu?
  • Katılıyorum. Bu tür sistemleri güvenilir kılmanın tek yolu problemi küçük parçalara bölmek. İç tutarlılık kontrolleri de sonuçta sadece LLM’lerin beklediğinizden çok daha az tutarlı olduğunu gösteriyor
  • apply_patch benzeri bir araca check_compilation ve run_unit_tests ekleyince performans ciddi biçimde iyileşti. Aracın adı hâlâ apply_patch, ama artık patch başarılı olursa build ve test hakkında ek bilgi de döndürüyor
    Ajan başarı oranı yaklaşık %80’den, şu ana kadar neredeyse deterministik görünen bir seviyeye çıktı. Artık prompt içinde derleme ve birim test sürecini ayrıca açıklamama gerek kalmıyor; belirli bağımlılıklarla çalıştırıldığında sadece sonucu döndürmesi yetiyor
    Biraz da güncel modanın dışına düşmüş gibi hissediyorum. Uzun zamandır peşin token ve custom harness kullanıyorum ve düpedüz iyi çalışıyor. Haberlerin çoğu görmezden gelinebilir. Açıkça hedeflediğiniz problemlerde Copilot tarzı araçlar artık işe yaramaz hale geliyor ve bazı codebase’lerde aynı GPT 5.4 tabanlı modeli kullansanız bile performans bambaşka bir düzeyde oluyor
  • İşin sırrı, o orkestrasyon prompt’unu “compile etmek”. Prompt’u koda dönüştürürseniz, o kod yeniden ajan çalıştırabilir, kod çalıştırabilir ya da ikisini birden yapabilir; böylece determinizm sorunu çözülür
    Herkes skill’lerde bu deseni kaçırıyor. SKILL.md dosyasının yanına kod koyarsanız belirli davranışları garanti edebilirsiniz ama insanlar tuhaf biçimde prompt yazmaya bağımlı kalmış durumda. CLI yapmanız da gerekmiyor; işlerin içinde olduğu basit bir skill.py yeterli. Hatta claude -p çağıran bir helper bile koyabilirsiniz

• Birkaç yıl sonra insanların hâlâ LLM kullanıp bunu da sonunda öğrenmeleri gereken kontrollü bir sözlük ve dilbilgisi üzerinden yapmaları komik olurdu. Tıpkı 15 yıl önce herkesin NoSQL’e geçip hemen sonra JSON’un içine yeniden şema kurması gibi

• Sorunun bir kısmı belki de en başta LLM’leri yanlış uyguluyor olmamızdır. Başka yerlerde de dendiği gibi, ajanın prompt’u mümkün olduğunca tekrarlanabilir, doğrulanabilir ve deterministik şekilde işi yapan kod yaz olmalı olabilir
  Buna ajan çıktısının doğrulanması da dahil olmalı. Genel hedef, programlarla daha verimli ve çoğu zaman daha doğru biçimde çözülebilen işlerde LLM’yi devreden çıkarmak olmalı

  • Buna %100 katılıyorum. %90 doğru bir deterministik olmayan aracı, %100 doğru deterministik araçlar üretmek için kullanmalısınız. Prompt’larıma mutlaka koyduğum kilit cümlelerden biri “belirsiz sınır durumlarıyla karşılaşırsan bana sor” oluyor
    AI’yi production’a bağlayıp API çağrısıyla doğrudan bir şey yaptırmak kötü bir fikir. Bir uygulamada AI’nin tek gerçek kullanımının okuma, sınıflandırma gibi işler olması gerektiğini düşünüyorum. Eski CRUD uygulamalarındaki “R” harfini ikame etmesi gibi
    Aynı AI tabanlı “R” endpoint’i ile prompt’a göre “C”, “U”, “D” formlarını otomatik doldurmak sorun değil, ama bir insan incelemeden önce müşteri adına bir şeyi değiştirmemeli. CRUD uygulamaları hâlâ CRUD uygulamalarıdır ve öyle kalacak; sadece artık müşterilere, iç araçlara ya da Jenkins pipeline’larına form otomatik tamamlama veya aksiyon önerileri sunan çok akıllı bir “R” endpoint’imiz var. Eylem önerebilir ama kendisi uygulamamalı
  • Çoğu organizasyonda akışın llm -> prompt -> result, llm -> prompt + prompt encoded as skill -> result, llm -> prompt + deterministic code encoded as skill -> result şeklinde ilerlediğini görüyorum
    Başta kod üretimini prompt’la yaptırmak, deterministik koda giden yolu kısaltabilir ama hâlâ deterministik olmayan bir sarmalayıcının içine deterministik kod koymuş oluyorsunuz. Uzun vadeli görevleri başarıyla tamamlamak için çoğu durumda eksik olan şey bu determinizm katmanı
    Deterministik kodu ajan döngüsünün ya da framework’ün dışında, deterministik olmayan sınırın ötesine koymanız gerekiyor. Böylece deterministik ajan akışı -> deterministik olmayan karar verme -> deterministik araçlar gibi, deterministik olmayan muhakemenin determinizm katmanları arasına sıkıştığı bir düzen elde ediyorsunuz. Deneylerimde çok güçlü bir desen oldu; auto-researcher gibi araçlarla ajan kendi determinizmini üretirse daha da güçlü hale geliyor
  • Biz de aynı deneyimi yaşadık. Başta ajana veri yapılarını belirli şekilde manipüle edebilecek araçların listesini verdik ama bu yaklaşım oldukça kırılgandı
    Şimdi küçük bir alan özel dili ve tek bir araç kullanıyoruz; ajan bu dilde yazdığı script’i girdi olarak veriyor. Daha dinamik kullanım senaryolarını kapsayabiliyor ve hatalı sözdizimi parser tarafından kolayca yakalanıp ajana geri döndürülebiliyor
  • Sorun şu ki programlar sık sık yorum gerektiren sınır durumlarıyla karşılaşıyor ve o anda LLM’nin bu sınır durumlarını ele almasını istiyorsunuz; sonra da yavaş yavaş tüm döngüyü ve araç çağrılarını da LLM’ye bırakmak istiyorsunuz
  • Son projemde, donanımı kontrol eden sunucu ile mobil uygulama arasındaki arayüz kütüphanesinin üretimini otomatikleştirirken tam olarak bunu yaptım
    Donanım kontrol ekibi spesifikasyonları belge ve spreadsheet’lerle veriyordu; mobil ekip bunları kullanarak arayüz kütüphanesini kodluyor ve sunucuyla eşleştiğini doğruluyordu. Ben belgeleri TSV’ye dönüştürdüm ve bir kısmını Claude’a verip insan yazımı spesifikasyonların ince nüanslarını koruyan bir TSV parser yazdırdım
    Tüm sınır durumlarını ele alıp ara sonuçları JSON olarak üretmesi için 150’den fazla iterasyon gerekti. Sonrasında Claude, Apollo üzerine custom glue code ekleyerek mobil uygulamanın tüketeceği kodu üreten bir code generator yazmama yardımcı oldu
    Bu pipeline’ın tamamı Github Actions’ın bir parçası olarak çalışıyor ve yalnızca kütüphane doğrulayıcısı başarısız olduğunda Claude çağrılıyor. Hata olduğunda neyin yanlış gittiğini belirlemesi, çözüm önermesi ve PR oluşturması için isteğe dahil edilen bir md dosyası var. Sonra insan gözden geçiriyor, düzenliyor ve merge ediyor. Buraya kadar toplam kredi maliyeti 350 doların altında kaldı

• Ana fikre katılıyorum ama sonucun değişmesi gerektiğini düşünüyorum. Prompt’un sınırına çarptığınızda, çalışma zamanında işi LLM’ye yaptırmaya çalışmak yerine işi yapacak yazılımı LLM’ye yazdırmalısınız
  Çalışma zamanındaki LLM rolü genellikle, kullanıcının katı iş kuralları gömülü yazılım sistemine uygun girdileri seçmesine yardımcı olmaya kadar küçülecek

  • İş yerinde birkaç haftalık boşluk yakaladım ve not alma, iş takibi, doküman yönetimi gibi iş süreçlerine ajan koymayı denedim; bu yorum deneyimimle birebir örtüşüyor
    İlk hafta prompt’lar sürekli büyüdü ve performans düştü. İkinci haftada notlar, görevler, projeler, insanlar gibi nesneleri doğru tanımlamaya ve bu nesneler üzerinde iyi tanımlı işlemler yapan method’lar tanımlamaya odaklandım. Dediğiniz gibi ajan yüzeyi, doğal dili girdi doğrulayıcısından geçen komut ve argümanlara çeviren bir çeviri katmanına indi
  • Tam tur dönen bir system prompt olsaydı muhtemelen şu olurdu: “kendini işsiz bırakmak için otomatikleştirebileceğin her fırsatı ara. Kodun cevaplayabileceği bir soru aldığında, kodu yaz ve çalıştır, sonucu elde et ve onunla cevap ver”
    Böyle bir LLM belki strawberry testinde daha iyi sonuç verirdi
  • Bu forumda da yazılımın geleceğinin, generative AI kullanılarak çalışma zamanında üretilen ve uyarlanan programlarda yattığını düşünenler vardı. Oraya ne kadar kaldığını bilmiyorum
  • Modellerin belirli problem çözme biçimlerine saplanıp kaldığı ve farklı yönteme geçmeleri için hafif bir dürtü gerektiği durumlar gördüm. Örneğin bir ses akışının hotplug/unplug durumunu ele almak için bir sürü system service ayarıyla uğraşmak yerine, aslında gereken şey birkaç düzine satır Python yazmaktı
    Claude’a workflow’umda test çalıştırma gibi yaygın durumları ele alan birkaç shell script’i kendisinin yazdırdım. Artık 30 dakika boyunca dönüp durmak yerine bu araçları çalıştırıp kurulumu tamamlıyor
    Bir şeyi yapmak için tek seferlik tuhaf shell ya da Python one-liner’ı çalıştırma izni istediğinde, otomatik onay verebileceğim bir aracı kullanması gerekip gerekmediğini düşünmeme yol açıyor

• Bu yüzden sık sık “bir sonraki nesil AI” ifadesi kullanılıyor. Burada kasıt sadece LLM değil. LLM’ler oldukça etkileyici ve temel düzeyde daha fazla ilerleme olmasa bile, daha ilginç biçimlerde kullanılıp optimize edilerek değer üretmeye devam edeceklerini düşünüyorum
  Ama bazı yönlerde, hangi biçimde olursa olsun temelden bir sonraki nesil iyileştirme gerekiyor gibi görünüyor. LLM’lerin “asla X yapma” talimatını bulanıklaştırıp, bir sürü görevden sonra bunu “lütfen X yap” gibi algılaması, çalışma biçimlerinin özüne yakın bir sorun gibi duruyor. Henüz neler yapabildiğimizi keşfetmenin ilk heyecanında olduğumuz için unutmak kolay ama LLM’ler AI’de aradığımız her şey değil
  “Asla X yapma”yı insanlar gibi ele alan yapılar gerekli. “Context window” yerine insana benzer bellek katmanlarına sahip yapılar da gerekli. Başlangıçta aynı AI olsalar bile, iki kişi yeterince uzun sohbet ettiğinde sonuçta ellerinde sadece farklı context window’lara sahip aynı AI değil, gerçekten iki farklı varlık olurdu
  Elbette bunun nasıl görüneceğini kimse bilmiyor. Ama LLM’lerin AI için nihai cevap olduğunu düşünmek için de bir neden yok

  • Bence gereken şey gerçek bellek. Bugünkü bellek, kabaca bakınca AI’nin kendi kendine yazdığı ve her seferinde dönüp baktığı yapışkan notlardan oluşan bir sisteme benziyor; öğrenmeyi mümkün kılan ve daha esnek biçimde devreye giren entegre bir sistem değil
  • İlginç bir örnek var https://www.youtube.com/watch?v=kYkIdXwW2AE&t=315s

• Prompt zorlaması → deterministik akış → prompt zorlamasına geri dönüş turunu yaşamış biri olarak katılmıyorum
  “Atlama yapma” talimatının başarısız olmasının nedeni, ajanın üstlendiği işin fazla büyük olması ve context içindeki diğer şeylerin dikkatini bu yönergeden çalması
  Ama zorlama işini yapan ajanın, işi üreten ajanla aynı olması gerektiğini söyleyen kimse yok. Deterministik kontrol akışına bir miktar akıllı karar verme mantığı kodlayabilirsiniz, ancak bunu fazla katı yaparsanız iyi çalışmaz; fazla karmaşık yaparsanız da kurulum ve bakım maliyeti nedeniyle doğrudan ajan kullanmak daha ucuz olur
  Temelde gereken şey üç tür ajan: döngüyü yöneten ve sorun çıkarsa uygun olanı devreye alan supervisor, uygun ajanlara delege eden ve gerektiği yerde guardrail uygulayan orchestrator ve iş birimlerini yürüten worker

  • Doğru, sadece daha fazla ajan eklemek yeterli

• Bana göre tüm harness’ler bu konuda hatalı ve bazıları çok ciddi biçimde hatalı
  Mesela slash command yanlış bir özellik. Context window durumunu ya da bu oturumda ne kadar para harcandığını görmek için chatbot’un bir turu bitirmesini beklemek zorunda olmamalısınız. Kontrol, sohbet döngüsüne dik olmalı
  Metin üretecinin giriş ve çıkışlarını kontrol etmekle ilgisi olmayan şeyler bile sırf “sohbet ediyoruz, o halde bunu IRC botu gibi çalıştıralım” mantığı yüzünden chat davranışına bağlanmış durumda
  Bugünlerde çok fazla LLM ajanı var ama kontrol, ajan döngüsü ve sunum katmanını düzgün biçimde ayıran neredeyse hiç yok. Bazılarında en azından headless mode var; o da iyi

  • Ne demek istediğini anlıyorum ama gerçekten önerdiğin mimariyi inşa etmek çok daha zor. Bunu kendin yapıp büyük teknoloji şirketlerinde iş kovalamayı denemeye ne dersin?
  • codex CLI’da /status tur sırasında da gayet çalışıyor
    Diğerlerinde öyle değil gerçi
  • Codex masaüstü uygulamasını kullanıyorum. GUI’de context göstergesi ve kullanım istatistiklerini görebiliyorsun
    Konuşmalar arasında gidip gelmek ve güncellemeleri görmek de daha rahat. Bazen terminalde Claude Code ya da opencode kullanıyorum ama deneyim, Codex masaüstü uygulamasına göre çok daha kötü

• “Cümlelerin öneri olduğu ve fonksiyonun halüsinasyon görerek ‘Success’ döndürdüğü bir programlama dili hayal edin. Akıl yürütme imkânsızlaşır ve karmaşıklık arttıkça güvenilirlik çöker” sözü özünde deklaratif programlamaya yakın
  Geleneksel programlamanın çoğu, geliştiricilerin aşina olduğu imperatif tarzdadır. Kesin talimat kümesini verirsiniz ve yazdığınız gibi uygulanmasını beklersiniz. Ajanlar ise imperatiften çok deklaratife yakındır; onlara sonucu verirsiniz, onlar da o sonuca ulaşmak için çalışır
  Elbette SQL gibi deklaratif sistemlerde sonuçlar oldukça tutarlı ve iyi tanımlıdır ama orada da nasıl işleneceği konusunda iç motora güvenirsiniz. Ajanları deklaratif olarak düşünmek, Rube Goldberg tarzı “kontrol” sistemleri tasarlamaya çalışmaktan çok daha faydalı oldu benim için. Uymuyorsa doğrular, yanlış olduğunu bildirir ve yeniden dener ya da başka yaklaşım seçersiniz
  Gerçekten imperatif gerekiyorsa imperatif yazarsınız. Ya da ajana öyle yazdırırsınız. Bu, işe uygun olmayan aracı kullanmaya çalışmak gibi geliyor

  • Deklaratiften de bir kademe daha soyut sanki. Belki buna “anlatısal programlama” denebilir? Tabii buna hâlâ “programlama” demenin uygun olup olmadığı bile tartışılır
    Deklaratif gibi görünebilir ama bu, illüzyonun içinde böyle. Aslında AI’ye hedefleri açıklayıp yorumlatmıyoruz; elimizde bir insan vekil karakterin bilgisayar karakteriyle konuştuğu bir hikâye dokümanı var ve biz gerçek dünyada, LLM’nin bunun arkasına daha tutarlı bir hikâye örmesini ve bizim de o hikâyeden faydalı bir şey çıkarabilmemizi umuyoruz
    Bu sadece akademik bir ayrım değil. Ortada bir hikâye olduğunu bilmek, girdi ve çıktı ilişkisinin nasıl anlaşılması gerektiği ve nasıl strateji kurulacağı konusunda daha iyi modeller veriyor. Örneğin prompt injection gibi riskleri anlamaya yardım ediyor ve hangi eğitim verilerinin eklenip çıkarılması gerektiği konusunda da yön gösteriyor
  • Aklıma deklaratif geldi ama SQL’den çok PROLOG düşündüm. Yani gerçek kontrol akışı ve muhakeme yeteneği olan türü
    Orada da LLM’lere benzer sorunlara, yani çok dikkatli olmazsanız sessiz başarısızlıklara, döngülere ve çelişkilere çarpıyorsunuz. Özünde aynı closed world assumption sorunu olabilir. LLM’lerde bu, bilmediğini kabul etmek yerine halüsinasyon olarak ortaya çıkıyor
  • Katılıyorum. Ama ajanla imperatif de konuşabilirsiniz. “İşte somut adımlar, bunları takip et” deseniz bile yine batırabilir. Burada aranan şey imperatiflik değil, determinizm
    Ve dediğiniz gibi, deterministik olmayan bir LLM’ye deklaratif biçimde “beni şu nihai duruma götür” derseniz raydan çıkma ihtimali daha da yükselir
  • SQL’in deklaratifliği, ilişkisel cebir gibi bir matematiğe dayanır; bu yüzden her seferinde aynı sonucu döndürür. Her sorgunun aynı sürede dönüp dönmemesi indekslere ve veritabanı boyutuna bağlıdır
    Ama sorgunun kendisi LLM gibi değişmez

• Bu mesele üzerine epey düşündüm. Uzmanlaşma tartışmasıyla da ilişkilendirilebilir. Model ne kadar uzmanlaşırsa temel düzey yeteneklerinin o kadar gerilediği görülüyor; çok hafif bir soyutlama düzeyi hedeflenirse iki tarafın da avantajı alınabilir gibi
  Oldukça spesifik bir örnek ama düşünmeye değer
  Podcast’in 20 dakikalık özeti: https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.ht...
  Makale: https://arxiv.org/abs/2605.00225

• Bu, 2023’teki Auto-GPT döneminde de zaten görünüyordu. İnsanlar GPT’nin “sürmesine” izin veriyordu ama çoğu durumda gerçekte gereken şey 10 satır Python ve belki birkaç llm() çağrısıydı
  Alternatif ise o 10 satırlık Python’u mümkün olan en pahalı, en yavaş ve en az güvenilir şekilde çalıştırmaktı. Tabii popülerdi
  Örneğin çoğu kişi ajanları internette araştırma yapmak için kullandı. Saatlerce çalışıp dikkati dağılıyor ya da başlangıçta yaptığı işi unutuyordu
  Oysa import duckduckgo ve import llm ile 20 saniyede aynı işi yapan 10 satırlık kod yazabilirsiniz; gerçekten deterministik çalışır ve maliyeti 50 kat daha düşüktür
  Mevcut modeller çok daha iyi ve Auto-GPT’nin artık gerçekçi olacağı kadar iyiler. Ama kötü tanımlanmış kontrol akışını mümkün olan en pahalı şekilde yürütmek hâlâ kötü bir fikir olmaya devam ediyor