İnsanlar hâlâ klavyenin önünde oturup akıllı sistemlere satır satır talimat vermek zorunda kalırken, temel beceri uyarı metni yazmak oldu. Bugün, akıllı sistemler bir hedef alıp kendi kendilerine çalışabiliyor; yeni temel beceri döngü mühendisliği.

Yazı yazarı: CyrilXBT

Makale çevirisi, kaynak: ME News

Haziran 2026'da, bir hafta içinde üç kişi bağımsız olarak aynı sonuca vardı.

OpenClaw'un geliştiricisi Peter Steinberger, insanların doğrudan programlama ajanlarına talimat vermek yerine, ajanlara otomatik olarak komut veren döngüsel sistemler tasarlamalı olduğunu açıkladı.

Neredeyse aynı anda, Anthropic Claude Code sorumlusu Boris Cherny, artık Claude'a doğrudan talimat girmeyi bıraktığını belirtti. Şimdi, Claude'u otomatik olarak çağırıp bir sonraki adımın ne olacağını belirleyen döngüler çalıştırıyor ve gerçek işi bu döngüleri yazmak ve tasarlamak.

Birkaç gün sonra, Google mühendisi Addy Osmani bu uygulamayı sistematik bir şekilde özetledi ve bir isim verdi:

Loop Engineering, Döngü Mühendisliği.

Bu çalışma şeklini boştan yaratmadılar, zaten sessizce gerçekleşen bir değişikliğe isim verdiler.

Daha önce, temel araçlar bir kritik eşiği aştı: programlama ajanları, insan müdahalesi olmadan gerçek görevleri tamamlayabilmeye başladı; otomatik zamanlama maliyeti yeterince düşüktür ve bir görevi tekrar tekrar zamanlı olarak çalıştırmak artık kayıp gibi görünmüyor; tek bir ajan çalıştırmasının maliyeti de yeni bir seviyeye indi—bir kez dikkatle düşünmek yerine, beş kez denemek daha düşük maliyetli olabilir.

Bu tam olarak bu rota haritasının var olma nedenidir.

İnsanlar hâlâ klavyenin önünde oturup akıllı sistemlere satır satır talimat vermek zorunda kalırken, temel beceri uyarı metni yazmak oldu. Bugün, akıllı sistemler bir hedef alıp kendi kendilerine çalışabiliyor; yeni temel beceri döngü mühendisliği.

Bir uyarı ifadesi operatöründen sistem tasarlayıcısına tam 20 adımlık bir yol aşağıda verilmiştir. Adımlar arasındaki sıralama, herhangi bir tek adım kadar önemlidir, bu nedenle sırayla ilerlemek zorundasınız.

Döngü mühendisliği, "kavranmış" veya "kavranmamış" tek bir beceri değildir; katmanlı bir yetkinlik yığınıdır. Her katman, alttaki temelin yeterince sağlam olmasına bağlıdır.

Örneğin, 14. adımdaki otomatik zamanlama tetikleyicisini, 10. adımda gerçek durdurma koşulları oluşturmadan doğrudan kurmak, insan müdahalesi olmadan otomatik olarak para harcayan bir sistem elde etmenize neden olur. Geçmişte en azından ekranı izlediğinizde kaynak harcıyordu, şimdi kendi kendine sürekli para yakabiliyor.

Aynı şekilde, 6. ve 7. adımların güvenilir doğrulama mekanizmasını tamamlamadan önce 11. adımdaki kalıcı bellek katmanını kurarsanız, çok gevşek ve sürekli hatalı sonuçlara izin veren bir “değerlendiricinin” topladığı deneyimleri ciddiye alabilirsiniz.

Bu, sistemin ilerlemesine yardımcı olmayacak, aksine yanlış deneyimlerin birikmesine neden olacak ve bellek katmanını “geçici olarak kullanışsız”dan “aktif olarak zararlı” hale getirecektir.

Bu nedenle, bazı adımları atlamak sadece bir fonksiyonun eksik kalması anlamına gelmez. Daha ciddi olan, görünümden etkileyici görünen ileri düzey yetenekleri, onları destekleyebilecek temel bir altyapı olmadan kurmak ve sistemin zaten ölçeklendirilmiş ve gerçek sonuçlar yaratmış olmasından sonra sorunların fark edilmesidir.

Birinci Aşama: Zihniyet Değişikliğini Tamamlayın 1. Adım: Sınırın modelde değil, sizde olduğunu kabul edin

Gerçek ilk adım herhangi bir teknikle ilgili değildir.

Mevcut iş akışında verimliliği sınırlayan faktörün genellikle model kapasitesi değil, sizin hâlâ döngüde kalmanız olduğu kabul edilmelidir.

Bilgisayarınızın önünde modelin cevabını beklerken, sonucu okuyup bir sonraki komutu girdiğinizde, tüm sistemin en yavaş bileşeni olursunuz.

Model, insanın adım adım görevi tamamlamasını izlemekten çok daha hızlı bir şekilde yürütülebilir, doğrulanabilir ve yeniden denenbilir.

Bu adım için karşılık gelen bir yönerge yoktur, bu bir bilişsel karar vermedir.

Bu noktayı gerçekten kabul edene kadar, tüm sonraki adımlar, sistemin en büyük verimlilik darboğazını kaldırmak oldukları gerçek anlamından ziyade, gereksiz ek işler gibi görünecektir.

Model çıktısı sorun yaşadığında, insanlar en doğal tepkilerini genellikle orijinal talimatlara yeni bir kural ekleyerek gösterirler.

Birkaç ay sonra bu uygulama, içeriği yoğun, birbirine çelişen ve modelin çalışma belleğinde aynı anda tüm talepleri işleyemeyeceği kadar uzun bir kural duvarı oluşturacaktır.

Sonuç olarak, modeller genellikle en son ortaya çıkan veya en belirgin görünen içeriklere göre desen eşleştirme yapar ve diğer kuralları farkında olmadan görmezden gelir.

Döngü mühendisliği bu düşünceyi kökten değiştirdi.

Sorun ortaya çıktığında, yeni bir talep eklemek yerine sisteme yeni bir bileşen ekliyorsunuz, örneğin:

• Bağımsız bir doğrulama adımı ekleyin;
• Bir bellek dosyası ekleyin;
• Bir zamanlayıcı tetikleyici ekleyin;
• Yapılandırılmış bir değerlendirme aşaması ekleyin.

Dış sistem kapasitesi arttıkça, talimat metni daha uzun değil, daha kısa olmalıdır.

Her görev ne alanda olursa olsun, döngünün her çalıştırılması beş temel eyleme ayrılabilir:

Tanımlama, devir, doğrulama, kalıcı hale getirme, zamanlama.

Keşif

Gerçekten tamamlanması gereken görevi anlayın.

Teslim alma

Görevi gerçekleştirmekten sorumlu model, ajan veya araca verin.

Doğrulama

Sonuçların gerçek standartlara göre kontrol edilmesi.

Sürekli kalıcılık

Bu çalışmanın ne olduğunu kaydedin, neler öğrendiğinizi not edin ve deneyimleri bir sonraki çalışmadan kaybetmeyin.

Planlama

Bu sürecin ne zaman tekrar çalıştırılacağını belirleyin.

Çoğunluğun mevcut iş akışı, yalnızca iki ilk eylemi: görev tanımlamayı ve görevi devralmayı açıkça içerir ve genellikle sohbet penceresinde elle yapılır.

Diğer üç eylem ya tamamen yoktur ya da insanın kendi zihninde gizlidir.

Döngü mühendisliğinin temeli, bu beş eylemi tamamen açık hale getirmek ve mümkün olduğunca otomatik çalıştırmaktır.

Sistemi kurmadan önce, tekrarladığınız ve kalite standartlarını açıkça tanımlayabildiğiniz bir görev seçin.

En zor soruları seçmeyin, tamamen örnek olmayan yenilikçi görevleri de seçmeyin.

İlk aday görev üç koşulu sağlamalıdır:

1. Bunu tekrar tekrar yapmalısınız;
2. Yazılabilir açık standartlara sahiptir;
3. Bir tanımlanabilir "tamamlandı" durumuna sahiptir.

Yani bir meslektaş, sonucu gördükten sonra bu görevin doğru şekilde tamamlanıp tamamlanmadığını hemen anlayabilmelidir.

Bu sınırlama, görünenden daha önemlidir.

Bir görevin tamamlanma kriteri net değilse, gerçek bir doğrulama aşaması oluşturulamaz. Güvenilir bir doğrulama mekanizmasına sahip olmayan bir döngü, gerçek bir döngü değildir; sadece kimse tarafından denetlenmeyen bir tahmindir.

Bu, çoğu kişinin atlaması en kolay adım olmakla birlikte, sonraki sistemin düzgün çalışıp çalışmayacağını belirleyen kritik adımdır.

Bir agente herhangi bir talimat yazmadan önce, doğru bir sonucun tam olarak nasıl olması gerektiğini açık ve doğal bir dille yazın.

İhtiyacınız olan, “iyi hissettirme” veya “profesyonel görünme” gibi bulanık kalite yargıları değil, somut ve denetlenebilir standartlardır.

Aşağıdaki şablonu kullanabilirsiniz:

Görev Adı: [Görev Adı]

Tamamlandı Tanımı (Definition of Done, DoD):

• [Spesifik, kontrol edilebilir kriter 1]
• [Spesifik, kontrol edilebilir kriter 2]
• [Spesifik, kontrol edilebilir kriter 3]

Son çıktı tamam ve dikkatle düzeltilmiş olsa bile, yukarıdaki herhangi bir şey eksikse, bu görev tamamlanmış sayılmaz.

Mevcut görev için bu şablonu dolduramıyorsanız, 4. adıma dönüp döngü oluşturmak için daha uygun bir görev seçin.

Bu, tüm döngüsel sistemlerdeki en önemli mimari karar.

Sonuçları oluşturan rol, sonucu kontrol eden rol ile birbirinden ayrı olmalıdır.

Nedeni, modelin içerik üretttikten hemen sonra kendi çıktısını incelediğinde, sorunları eleştirel bir bakış açısıyla değerlendirmek yerine, hemen ürettiği cevabı savunmaya eğilimli olmasıdır.

Bir dizi mantıklı döngüde en az iki bağımsız rol olmalıdır:

Yapımcı

Yapıcılar, ilk sürümün sonucunu oluşturmak için belirli bir yaratıcı alan sahiptir.

Değerlendirici

Değerlendiriciler, yapımcının çıktısını ve 5. adımda belirlenen tamamlama kriterlerini alır ve bu standartlara göre sonucun uygun olup olmadığını değerlendirir.

İdeal olarak, inceleyicilerin ayrıca oluşturucuların erişemeyeceği bağımsız kanıtlara da erişimleri olmalıdır, örneğin:

• Test seti;
• Kaynak materyal;
• Gerçek zamanlı veriler;
• Yetkili veritabanı;
• Orijinal görev tanımı.

Bu şekilde, değerlendirme yapacak kişilerin aynı düşünceyle tekrar bir öznel görüş üretmek yerine, gerçek kanıtlara dayalı karar verebilmeleri sağlanır.

Eğer değerlendiriciler yalnızca oluşturucunun çıktısını görebiliyorsa, yalnızca sonucun "tutarlı görünüp görünmediğini" değerlendirebilir.

Sonucun gerçekten doğru olup olmadığını belirleyemiyor.

Bu nedenle, inceleyicilerin doğrulanabilir bir nesnel temele, yani Ground Truth'a sahip olmaları gerekir. Bağlama göre bunu “temel gerçek”, “gerçek veri” veya “yetkili kaynak” olarak anlayabilirsiniz.

Farklı görevler için nesnel kriterler de farklıdır.

Programlama görevi

Nesnel kanıt, test suite ve kodun gerçek çalışma sonuçlarıdır.

İçerik Üretim Görevi

Objektif temel, orijinal kaynaklar ve içerik özetiyledir. Değerlendiriciler, orijinal kaynakları oluşturulan taslakla yan yana karşılaştırmalıdır.

Araştırma görevi

Objektif temel, görevin açıkça talep ettiği orijinal belgeler, makaleler, veri kümeleri veya yetkili kaynaklardır.

Eğer değerlendiricilerin neye dayanarak kontrol yapacağını açıkça belirleyemiyorsanız, döngünüzde gerçek bir doğrulama mekanizması yoktur, değerlendiricilerin ifadeleri ne kadar emin görünürse görünsün.

Yapımcının çıktısı ve inceleyicinin sonucu, serbest akışlı doğal dil yerine açıkça tanımlanmış bir yapıya sahip olmalıdır.

Aksi halde, sonraki yönetici, karar vermek ve yönlendirmek için istikrarlı ve güvenilir bilgilere sahip olmayacaktır.

Yapımcılar aşağıdaki çıktı formatını kullanabilir:

Yapımcı Çıktısı:

• Son teslim içeriği;
• Sonuca olan güven düzeyi;
• Bilinen belirsizlik.

Değerlendiriciler aşağıdaki çıktı formatını kullanabilir:

Değerlendirme Sonucu:

• PASS: Geçti;
• FAIL: Başarısız;
• Düzenlenmesi gerekiyor:
• Belirlenen sorunlar;
• Bu denetimin temel aldığı nesnel standartlar veya orijinal kanıtlar.

Otomatik zamanlama ve otomatik yeniden deneme öncesinde, tam bir "Yapımcı - İnceleyici" sürecini elle manuel olarak bir kez çalıştırın.

Verilen değerlendirmeyi dikkatlice okuyun ve kendinize sorun:

• Sonucu kabul ediyor musunuz?
• Bilinen bir hata olduğunu biliyorken bir sonucu serbest bıraktı mı?
• Önceden yeterli olan bir sonucu yanlışlıkla olumsuz mu yaptı?

Eğer bir değerlendirici, yanlış olduğunu bildiğiniz bir sonucu onaylarsa veya aslında sorunsuz olan bir sonucu reddederse, önce nesnel temelleri veya standartları düzeltin, ardından sistemi kurmaya devam edin.

Bir hatalı doğrulama adımını otomatikleştirmek, sistemin daha hızlı hatalı sonuçlar üretmesine neden olur.

Yukarıdaki beş adımı daha spesifik hale getirmek için, bir orijinal kaynağı tam bir makaleye dönüştürmek gibi yaygın bir görevi gözlemleyebiliriz.

5. Adım: Tanımı tamamlayın

Bu görevin tamamlanma kriteri şun olabilir:

• Tasarıdaki her bir gerçek, orijinal kaynaktaki açık bir içerikle izlenebilir;
• Taslak, haber bültenindeki tüm spesifik gereksinimleri, uzunluğu, tonu ve yapısını dahil olmak üzere karşılamaktadır;
• Ana argüman net bir şekilde korundu, anlamsız dolgu içeriklerle zayıflatılmadı.

6. Adım: Taslak oluşturun

Yapıcı, orijinal materyali ve içerik özeti alır ve bir taslak oluşturur.

Aynı zamanda, yazım sürecindeki belirsizlikleri açıkça listelemelidir, örneğin:

• Bir rakam orijinal kaynaktan gerçekten görünüyor mu;
• Bir sonuç, orijinal metinde açıkça ifade edilmiştir ya da model tarafından kendi kendine çıkarılmıştır;
• Bir gerçek yeterli kaynaktan yoksun mu?

7. Adım: Değerlendiriciler orijinal metinle kontrol edin

Değerlendiriciler, sadece taslak değil, taslak ve orijinal materyali aynı anda alır.

Tanımdaki üç kriteri ayrı ayrı kontrol etmelidir ve her bir kriter için geçti/kaçtı sonucunu ayrı ayrı vermelidir; tüm boyutları tek bir bulanık genel puanla birleştirmemelidir.

Üç farklı standartı bir genel değerlendirmeye birleştirmek, hangi boyutun sorun yaşadığını gizler. Bu, birçok zaman içinde geri bildirim değerini kaybeden döngünün en yaygın nedenidir.

8. Adım: Yapılandırılmış Teslim Alım

Değerlendiricinin sonucu, sakınca ifadelerle dolu bir doğal dil paragrafı değil, yapılandırılmış bir nesne olmalıdır.

Üç açıkça belirtilmiş başarılı veya başarısız sonuç verilmelidir ve her başarısızlık için özel nedenler sağlanmalıdır.

9. Adım: İnceleme mekanizmasını manuel olarak doğrulayın

Sistem otomatik olarak çalışmadan önce, bir tam işlemi elle gerçekleştirmek, değerlendirmenin çok gevşek veya çok sıkı olup olmadığını ortaya çıkarmaya yardımcı olur.

Aşırı gevşek bir inceleyici, makalenin akıcı yazılması nedeniyle içindeki sahte verileri göz ardı edebilir.

Aşırı katı bir inceleyici, bir raporda asla belirtilmemiş kişisel tercihler nedeniyle uygun bir makaleyi yanlışlıkla reddedebilir.

Bu iki soru, ilk kurulumda oldukça yaygındır.

Sistemin 50 kez otomatik olarak çalıştırılmasından sonra bunları tespit etmek, ilk elden test sırasında sorunları çözmekten çok daha maliyetli olur.

Yönetici, inceleyicilerin kararlarını okur ve sonraki adımı belirler.

Durdurma koşulları da yöneticide bulunmalı ve bir modelin kendi yorumuyla atlayabileceği yumuşak bir talimat yerine açık bir sert mantık olarak yazılmalıdır.

Örneğin:

Durdurma koşulu:

• Maksimum değişiklik sayısı: 3;
• Üçüncü değerlendirme hâlâ başarısız olursa, tam geçmiş insan eline teslim edilecek ve dördüncü düzenleme başlatılmayacaktır;
• Kalite standartları: Tanımda belirtilen her bir madde PASS olarak gösterilmelidir;
• Bütçe üst sınırı: Görev maliyeti X'i aşarsa veya çalışma süresi Y'yi aşarsa, mevcut durum ne olursa olsun hemen durdurulmalıdır.

Gerçek bir durma koşulu olmayan bir döngü, bir sistem değil, riskin ortaya çıkmasını bekleyen bir yükümdür.

Neden “sonuç yeterince iyi olduğunda dur” gibi yumuşak talimatlar güvenilir değildir?

Çünkü bu sadece bir öneridir.

Model, sürekli olarak birçok kez değiştirildikten sonra hâlâ geçemediğinde, görev için görünürde tatmin edici bir sonuç sağlamak amacıyla, bu sürümün standartlara yeterince yakın olduğuna kendini ikna ederek kendi değerlendirme eşiklerini düşürebilir.

Buna karşılık, kod tarafından mekanik olarak kontrol edilen yineleme sayısı veya yöneticinin akıl yürütme yoluyla atlayamadığı açık kurallar bu sorunu yaşamaz.

Bir döngü her başlatıldığında sıfırdan başlıyorsa, bir önceki çalışmadan öğrendiklerini hatırlamaz.

Bu nedenle basit bir kalıcı katman eklenmesi gerekmektedir.

Her gerçek yeni deneyim için bir dosya oluşturun ve dosyanın üst kısmına bir cümleyle özetleyin:

• Ne öğrendiniz;
• Ne düzeltildi;
• Bu deneyimin neden önemli olduğunu açıklayın.

Ana ilke, başka yerlerde kaydedilmemiş yeni bilgileri kaydetmektir.

Tekrarlanan bellek, bilgi değil, gürültüdür.

Sürekli mekanizmanın uzun vadeli etkili kalması için yazma sırasında ölçülü davranmak gerekir.

Tüm çalışma detaylarını kaydetme eğilimi kolayca ortaya çıkabilir, ancak bu, 2. adımda bahsedilen “aşırı uzun ipucu” sorununu tekrar yaratır; bu sefer şişmanlayan şey ipucu değil, bellek klasörüdür.

Gerçekten kaydedilmesi değerli deneyimler, bir kez unutulduğunda tekrar keşfetmek için çok zaman harcanması gerekenlerdir, beklenen şekilde sorunsuz tamamlanan sıradan bir çalıştırma kaydı değildir.

Sadece kalıcı bir mekanizma eklemek, nihayetinde uzun süreli ipuçları ile benzer sorunlara yol açacaktır.

Zamanla sistem, birçok dosyayı aynı sorunun hafifçe farklı ifadelerini içerecek şekilde birikir.

Bu nedenle, bellek dosyaları sabit bir periyotta düzenlenmelidir. Haftada bir kez yapmak genellikle uygun bir sıklıktır.

Düzenleme süreci şunları içerir:

• Mevcut hafızayı inceleyin;
• Tekrarlanan içerikleri birleştirin;
• Çok sayıda benzer deneyimi, daha net bir ilke haline getirin;
• Yanlış veya eski olduğuna kanıtlanan içerikleri silin.

Hedef, giderek artan dosya sayılarını biriktirmek değil, daha az sayıda ve daha yüksek bilgi yoğunluğuna sahip bilgi edinmektir.

Çok sayıda kişi, bu adımı hemen görünür yeni yetenekler sağlamadığı için tamamen atlar; sadece gelecekteki sorunları önler.

Ancak tam olarak çünkü anında geri bildirim yok, bellek klasörünün yönetilemez hale gelmesini beklemek yerine, bunu açıkça zamanlamalıyız.

Gerçek hayatta, bu "sonra zaman bulurum" görevleri genellikle, sistem performansı çelişkili, güncel olmayan ve kısmen ilgili belleklerin bağlam penceresi için rekabet etmesiyle düşmeye başlayana kadar asla gerçekleşmez.

Her yeni görev başladığında, döngü önce bellek dosyasındaki bir cümle özetini tarayarak hangi deneyimlerin şu anki görevle gerçekten ilgili olduğunu belirleyip yalnızca bu ilgili içerikleri yükleyin.

Ayrıca sistemden, mevcut bellekte mevcut görev için uygun hiçbir içerik yoksa, doğrudan uygun deneyim olmadığını belirtmesi istenmelidir.

Geçmiş deneyimleri tamamen farklı yeni bir soruna zorlamayın, çünkü hafıza sistemi zaten mevcut.

Sonrasında, bu döngünün elle başlatılmadan nasıl otomatik olarak çalıştırılacağına karar verilmelidir.

Tetikleme yöntemi şunları içerebilir:

• Cron zamanlanmış görevi;
• Dosya değişiklikleri izleyicisi;
• Takvim tabanlı döngü tetikleyicisi;
• Bir dış olay veya durum değiştiğinde tetiklenir.

Bu adım, yalnızca sizin elle başlatabileceğiniz bir sistemi, siz uyurken bile çalışmaya devam eden bir sisteme dönüştürecektir.

İlginç bir şekilde, bu genellikle listedeki en kolay gerçekleştirilebilir adım olur, ancak birçok kişi diğer bileşenleri tamamlamış olsa bile bu adımı hâlâ gerçekleştirmemektedir.

Döngüyü herhangi bir önemli görevde kullanmadan önce, dört hata moduna karşı aktif olarak test edilmelidir.

Test 1: Tamamlanamayan Görev

Bir sistem için gerçekten çözülemeyen bir görev verseniz, yöneticinin sonsuz döngüye girmeden durma koşullarına göre çıkıp çıkmadığını doğrulayın.

Eğer bir döngü yalnızca başarıyla tamamlanabilen görevlerde test edildiyse, zarif bir şekilde başarısız olma yeteneğine sahip olduğunu asla kanıtlayamadı.

Test 2: Görünüşte mantıklı ancak aslında yanlış sonuç

İnceleyicilere belirli olarak küçük hataların bulunduğu bir çıktı sağlayın.

Bu sonuç çok akıcı okunmalı, ancak içine kasıtlı olarak bir gerçek veya mantık hatası yerleştirilmelidir.

İçeriğin mantıklı görünmesi nedeniyle geçirmek yerine, inceleyicilerin sorunları tespit edip edemeyeceğini gözlemleyin.

Test 3: Yapımcılar ve Değerlendiriciler Modelin Boşluklarını Paylaşıyor

Yapımcı ve inceleyici aynı temel modeli kullanıyorsa, bu modelin sıkça yaptığı tipik bir hatayı kasıtlı olarak ekleyip inceleyicinin bunu gözden kaçıracak olup olmadığını gözlemleyebilirsiniz.

Eğer değerlendirme ekibi ile yapımcı aynı algısal boşluğu paylaşıyorsa, 6. adımda tasarlanan rol ayrımı anlamsızlaşır.

Test 4: En kötü durumda çalışma maliyetini hesapla

En fazla değiştirme sayısı, en pahalı model çağrısı ve makul sınırlar içinde en uzun çıktı kullanılarak bu döngünün en kötü senaryoda ne kadar maliyet harcayacağı hesaplanır.

Ardından kendinize dürüstçe sorun:

Bu rakam gerçek bir faturada görseydiniz, endişelenir misiniz?

Bu dört testi güven döngüsü önemli görevleri işlemeden önce tamamlayarak çoğu potansiyel sorunu önceden tespit edebilirsiniz.

Aksi takdirde, bu sorunlar muhtemelen müşteriler veya yöneticiler önünde ya da faturanızda ortaya çıkacak, sizin kontrol altına aldığınız bir testte değil.

Döngü stabil bir şekilde çalışır hale geldikten sonra, tüm karakterlerin aynı en sevdiğiniz modeli kullanmasına izin vermeyin.

Döngüdeki farklı roller, model yetenekleri açısından farklı taleplerde bulunur.

Yapımcı

Yapımcılar genellikle en güçlü modeli kullanmalıdır.

Çünkü ana karmaşık çıkarım ve içerik oluşturma görevini üstlenir. Burada yeterli kapasiteye sahip olmayan bir model kullanılırsa, ilk sürümün kalitesi düşer ve daha fazla düzeltme döngüsü gerekebilir.

Sonuç olarak, düşük kaliteli taslakları düzeltmek için harcanan maliyet, baştan daha güçlü bir model kullanmanın maliyetinden daha yüksek olabilir.

Değerlendirici

Değerlendiriciler, açık kriterlere göre kontrol yapmakla sorumludur ve genellikle büyük yaratıcılık gerektirmez.

Standartlar yeterince spesifik olduğunda, daha küçük, daha düşük maliyetli ve daha hızlı bir model, genellikle inceleme görevini güvenilir şekilde yerine getirebilir.

Çok açık bir kontrol listesine dayalı olarak çalışan küçük bir model, büyük modellere yakın istikrar gösterebilir, ancak maliyeti ve gecikmesi önemli ölçüde daha düşüktür.

Yönetici

Yönetici, zaten yazılan kurallara göre yönlendirme yapar ve neredeyse asla en pahalı modeli kullanmaz.

Görevi, tanımlanmış mantığı çalıştırmaktır, açık uçlu akıl yürütme yapmaz.

Ayrıca, oluşturucu ve inceleyicinin performansına bakılmaksızın, yönetici her yineleme turunda en az bir kez çalıştırıldığından, tek bir çağrısının maliyeti özellikle dikkat çekicidir.

Mantıklı katmanlandırma yapılandırması genellikle şöyledir:

• Güçlü model tarafından oluşturuluyor;
• Düşük maliyetli ve kararlı modeller, düzenli incelemeleri yürütüyor;
• Düşük maliyetli modeller veya kurallar, yönlendirme ve yönetimi sorumlu tutar.

Döngüsel sistemde gerçekten önemli maliyet tasarrufları, genellikle bu model rol eşleştirmesinden kaynaklanır.

Çok sayıda kişi maliyeti kontrol etmenin döngü sayısını azaltmak veya revizyon sayısını değiştirmek anlamına geldiğini düşünür. Aslında, daha etkili yöntem, model maliyetini döngüdeki her rolün gerçek zorluk seviyesiyle eşleştirmektir.

İlk döngü başarıyla tamamlandıktan sonra, insanlar genellikle hemen beş farklı görevi paralel olarak işlemek için birden fazla döngü kurmaya çalışır.

Mevcut mimarinin bu genişlemeyi destekleyebilmesine rağmen, bu dürtüyü kontrol altında tutmalısınız.

İlk döngünün, her çıktısını yakından kontrol etmenize gerek kalmayana kadar yeterince uzun süre stabil bir şekilde çalışmasını sağlayın.

Bu, herkesin dikkatle izlediği bir gösterinin tam olarak başarılı olması anlamına gelmez; bunun yerine, gerçek bir çalışma süresi geçtikten sonra hala el ile denetimlerle sürekli olarak geçerli kalması anlamına gelir.

Bu duruma ulaşılana kadar ikinci döngüyü oluşturmak不应 başlanmalıdır.

İkinci döngü, ilk döngüden açıkça farklı bir görevle ilgilenmelidir.

Bu, temel mimarinin yalnızca aynı görev için giderek daha ince ayarlar yapılması değil, gerçek genel bir yapıya sahip olup olmadığını doğrulamak için gereklidir.

Birden fazla döngüyü aynı anda çalıştırdıktan sonra, her döngüyü ayrı ayrı izlemek yerine, tüm döngülerin maliyetlerini ve durma koşullarının tetiklenmesini merkezi bir izleme görünümünde takip etmeniz gerekir.

Tek başına bakıldığında, bir döngüsel görev bütçesi tamamen mantıklı olabilir.

Ancak eğer on döngü her biri bütçe içinde çalışırsa, toplam maliyeti hâlâ beklenmedik bir seviyeye ulaşabilir.

Her döngünün bağımsız verileri normal göründüğü için bu risk genellikle toplu fatura ortaya çıkana kadar fark edilmez.

Başarıyla tamamlanan görevlerin yanı sıra, her durdurma koşulunun tetiklenmesi de özel olarak kaydedilmelidir.

Eğer bir döngü sıklıkla maksimum değiştirme sayısına ulaşırken diğer döngülerde bu durum nadiren görülüyorsa, bu durumun ilettiği mesaj “bu görev özellikle zor” değil:

• Değerlendirme kriterleri uygun değil;
• Değerlendiriciler çok katı oldular ve hiçbir sonuç geçemedi;
• Sistem, hatalı nesnel temelleri kontrol etti;
• Tanımı tamamlamak kendinde bir sorun taşımaktadır.

Sadece başarılı sonuçları izleyip her insan yükseltmesini birbirinden bağımsız rastgele olaylar olarak kabul ederseniz, bu tasarım düzeyindeki desen fark edilmeyecektir.

Düşünce dönüşümünün gerçekten tamamlanıp tamamlanmadığının en açık ölçütü, günlük dikkat ettiğiniz göstergelerin değişmesidir.

İpucu operatörünün ilgilendiği şey:

• Bugün kaç geçerli ipucu yazıldı;
• Hangi ipucu en iyi sonuç veriyor;
• İpucu metnini daha zarif nasıl yazabilirsiniz?

Sistem tasarımcıları şunu endişe ediyor:

• Şu anda kaç döngü çalışıyor;
• Her döngünün güvenilirliği nedir;
• Sistem kendisi için ne kadar zaman serbest bıraktı;
• Hangi işler artık insan gözetimi gerektirmiyor?

Hala kaç adet ipucu girdiğinizle verimliliğinizi ölçmeye devam ediyorsanız, ne kadar çok döngü teknik olarak kurulmuş olursa olsun, 1. adımda istenen düşünce dönüşümü hâlâ tamamlanmamıştır.

Son adım artık tamamen kendi sisteminizle ilgili değil.

Bu, sizin bu yöntemi gerçekten anladığınızı doğrulamak için kullanılır.

Bir başkasına karmaşık terimlerden yararlanmadan beş temel eylemi açıklamalısınız:

Tanımlama, devir, doğrulama, kalıcı hale getirme, zamanlama.

Eğer bu beş hareketi ve önceki adımları yalnızca kullanarak bir başkasının ilk döngüsünü kurmanıza olanak tanıyorsanız, bu rota haritasında tanımlanan gerçek dönüşümü tamamlamış olursunuz.

Artık döngü içinde kalıp sürekli bir sonraki komutu giren kişi değilsiniz.

Döngünün dışında duran, sistemi tasarlayan ve kendi kendine çalışmasını izleyen kişi oldunuz.

Adımları atladığınızda sessizce biriken dört maliyet

Makalenin sonunda bir uyarı vermek gerekir.

Bu rota haritasındaki adımları atlamak, genellikle sistemde hemen bir çökme yol açmaz.

Başarısızlığı genellikle sessizdir ve sorunlar oldukça ciddi hale gelene kadar uzun bir süre fark edilemez.

6. ve 7. adımları atlayarak gerçek bağımsız bir inceleyici oluşturmadığınızda ve güvenilir nesnel bir temel sağlamadığınızda, borç doğrulama birikmeye başlar.

Döngü, sonuçların "iyi göründüğü" için hâlâ normal şekilde çalışıyor gibi görünüyor.

Yüzlerce çalıştırma sırasında bir hata birikerek nihayet fark edildiğinde, sistemin başından beri sonucun doğru olup olmadığını gerçekten değerlendirmediğini anlarsınız.

20. adımı atladığınızda anlama bozulması ortaya çıkabilir.

Kendiniz oluşturduğunuz döngüyü hâlâ çalıştırıyorsunuz, ancak her bileşenin neden var olduğunu açıklayamıyorsunuz ve sistem arızasında etkili bir şekilde hata ayıklama yapamıyorsunuz.

Çünkü bu mimarinin arkasındaki mantığı gerçekten içselleştirmediniz.

Eğer 1. adım asla tamamlanmazsa, bilişsel teslimiyet ortaya çıkar.

Doğrulama sistemi uzun süreli kullanımla güvenilirliğini kanıtlamış olsa da, alışkanlık nedeniyle her çıktıyı elle kontrol edersiniz.

Bu davranış dikkatli görünse de, sistemi kurmanın tamamını iptal eder.

10. adımı atlamak, döngü için gerçek bir durdurma koşulu ayarlanmaması durumunda Token tüketimini ve çağrı maliyetlerini kontrolsüz hale getirebilir.

Sistemin kontrolü kaybettiği ilk anda genellikle sorunu fark etmezsiniz; sonunda fatura ortaya çıkana kadar döngünün çok sayıda geçersiz çağrı yaptığını öğrenirsiniz.

Yukarıdaki tüm maliyetlerden kaçınılabilir.

Onları kaçınmanın yolu her zaman aynı disiplindir:

Görünüşte yeterince harika olmayan adımları atlamadan, sırayla oluşturun.

Genellikle en sıkıcı kısımlar gerçekten işe yarar:

• Net tamamlama tanımı;
• Güvenilir durdurma koşulları;
• Doğrulanabilir nesnel kanıtlar;
• Bağımsız değerlendirme mekanizması.

Karşılaştırıldığında, daha çekici gelen kısımlar—zeki ipuçları, karmaşık sistem mimari diyagramları—insanların düşündüğü kadar önemli değildir.

Sistemin kalitesini gerçekten belirleyen, oluşturduğunuz sistemin şunu bilip bilmediğidir:

• Kendinizin ne zaman doğru olduğunu;
• Kendi hatanız ne zaman olur;
• Ne zaman durulmalıdır.

Bu, talimat veren ile sistem tasarlayıcı arasındaki tüm farktır.

Fark, daha akıllı olanın kim olduğu ya da daha süslü talimatlar yazabilenin kim olduğu değildir.

Gerçek fark, sıkıcı ve atlanmak kolay olsa da sistemin güvenilirliğini gerçekten belirleyen bölümleri ciddiyetle oluşturmak için yeterli disipline sahip olup olmadığınızdadır.