Yaklaşan Döngü
(lucumr.pocoo.org)- Kodlama ajanının dışında, iş kuyruğu ve harness'in yinelemeyi yönettiği harness düzeyi döngü, ajan mühendisliğinde yeni bir merkezî desen olarak öne çıkıyor
- Model ne kadar uzun süre otonom çalışırsa, güçlü invariant'lar yerine yerel savunmalar ve fallback'ler eklemek o kadar kolaylaşıyor; bu da uzun vadede korunacak kodda tasarım anlayışı ve denetimin sarsılmasına yol açabiliyor
- Buna karşılık, kod taşıma, performans deneyleri, güvenlik taraması ve araştırma gibi sonuçların doğrulanmasının ya da atılmasının kolay olduğu alanlarda mekanik yineleme zaten güçlü biçimde çalışıyor
- Saldırganlar ve raporlayıcılar döngü çalıştırdığında, bakımcılar da triage, yeniden üretim ve müdahale için makine kullanma baskısı hissediyor; curl örneği, yapay zeka üretimi raporların oluşturduğu yükü gösteriyor
- Bundan sonraki mesele, döngü kullanıp kullanmamak değil; onun içinde de insan muhakemesini, mühendislik kurallarını, sorumlu gözetimi ve anlaşılabilir mimariyi korumak
Kodlama ajanının dışında dönen döngü
- Kodlama ajanının içinde zaten modelin araç çağırdığı, sonuçları yansıttığı, dosyaları okuyup düzenlediği, testleri çalıştırdıktan sonra yanıt verdiği bir ajan döngüsü var
- Yeni öne çıkan desen, bunun dışındaki harness düzeyi döngü
- İş kuyruğa girer
- Makine işi alıp denemeye başlar
- Durduktan sonra harness, işin gerçekten bitip bitmediğine karar verir
- Bitmediyse aynı oturuma mesaj enjekte eder, düzeltilmiş bağlamla yeni bir oturum başlatır ya da işi başka bir makineye devreder
- Bu dış döngü, modelin normalde “bitti” diyeceği noktadan sonra da işi canlı tutar
- Döngünün kendisi yeni değil, ama son dönemde ajan mühendisliğinde ve Twitter söyleminde daha sık görünmeye başladı
- Pi üzerinde de bu akışın bir kısmı görülüyor ve Pi bir harness olduğu için bu tür deneylerin merkezinde yer alıyor
Uzun süre korunacak kodda ortaya çıkan rahatsızlık
- Derinden önemsenen kod için bu yaklaşım hâlâ pek uygun değil
- Mesele özünde zevk ve denetim
- Üretime alınan kodu anlamak istenir
- Baskı altında ya da başkalarıyla tartışırken, önce makineye anlattırmadan sistemin nasıl çalıştığı açıklanabilmelidir
- Şu an için kodu anlamak hâlâ önemlidir
- El değmeden üretilen kodda, özellikle döngüden çıkan kodda, tekrar eden sorunlar var
- Fazla savunmacı olması
- Fazla karmaşık olması
- Yerel akıl yürütmeye saplanması
- Güçlü invariant'lardan kaçınması
- Hatalı durumu imkânsız kılmak yerine fallback eklemesi
- Yinelenen kod ve kötü soyutlamalar üretmesi, belirsiz tasarımı daha fazla mekanizmayla örtmesi
- Claude Code ve Fable gibi birleşimler, tek bir problem üzerinde 30 dakikadan uzun süre kesintisiz çalışabildiği için eskisine göre human in the loop daha az
- Şu anda el değmeden çalışan harness yaklaşımının ürettiği kod kalitesi, geçen sonbahara göre daha bile kötü hissettiriyor; en azından bu zevk anlayışında neredeyse hiç iyileşme görünmüyor
Döngü, modelin alışkanlıklarını büyütüyor
- Model, yerel bir başarısızlık gördüğünde yerel bir savunma ekleme eğiliminde
- Andrej Karpathy, modellerin istisnalardan “ölümcül biçimde korktuğunu” söylemişti
- Önemli invariant'ları olan sistemlerde, özellikle kalıcı veri formatlarında ya da çekirdek altyapıda, “her malformed case'i ele alma” yaklaşımı doğru düzeltme olmayabilir
- Daha iyi yön, malformed case'in ifade edilememesini ya da en baştan yazılamamasını sağlamaktır
- LLM'ler yoğun manuel yönlendirmeyle bile bu tür kodu doğal biçimde üretmekte zorlanır ve artık imkânsız hâle gelmiş hataları bile ele almaya çalışabilir
- Bu alışkanlık bir döngünün arkasına konduğunda sorun büyütülür
- Her yineleme küçük bir savunma daha ekler
- Sistem daha dayanıklı görünür ama giderek anlaşılması zorlaşır
- İnsan elini ne kadar çekerse bu eğilim o kadar güçlenir
- Böyle araçlar, net rehberlik olmadan junior geliştiricilere verilirse kötü pratikleri öğretebilir
- Nedenleri sorulduğunda da seçimlerini kulağa makul gelen şekilde savunabilirler
Döngünün iyi uyduğu alanlar
- Döngü deseni bazı alanlarda zaten çok iyi çalışıyor
- Kod taşıma bunun tipik örneği
- Bun'un bazı parçalarının Zig'den Rust'a taşınması gibi büyük ölçekli otomatik taşıma örnekleri var
- MiniJinja'nın Go'ya taşınmasında da başarıyla kullanıldı
- Performans keşfi için de uygun
- Makine deneyler dener
- Benchmark çalıştırır
- Başarısız olanları atar
- Keşfe devam eder
- Güvenlik taraması ve neredeyse her tür araştırmaya da doğal biçimde uyuyor
- Karmaşık problem uzayları keşfedilip sonuçlar raporlatılabilir
- Uzun süre yaşayacak kodun mutlaka commit edilmesi gerekmez
- Başarılı örneklerin ortak yanı; çıktının uzun süre korunmasının gerekmemesi, mevcut kodu dönüştürmesi ya da proof of concept, fikir, bulgu ve mekanik dönüşüme daha yakın olması
- Harness'in ihtiyaç duyduğu şey tamamen nesnel ya da ikili bir sinyal değil, bir sonraki yinelemeyi itecek kadar faydalı bir sinyal
- Başarılı örneklerin çoğu başka bir LLM'i judge ya da orchestrator olarak kullanıyor
- Mekanik çeviri ikili test case'lerle doğrulanabilir ya da LLM ile değerlendirilebilir
- Claude Code, tüm deney iş akışını kurup çalıştırmada giderek daha yetkin hâle geliyor
- Üretilen kod dağınık olsa bile, bu harness'in karar verme yetisinden çok modelin sorununa daha yakın
Yazılımı makineden çok organizma gibi ele almaya doğru değişim
- Kalıcı olacak kodu aynı döngü yöntemiyle yazmak hâlâ rahat hissettirmiyor
- Önceki ideal, yazılımı deterministik bir makine gibi anlamaya daha yakındı
- Bir katman açıldığında daha derin anlayış elde edilebilirdi
- Deterministik olmayan şekilde gözlenen makine, ideal kabul edilmezdi
- Mimarinin daha fazla determinizme gitmesi arzu edilirdi
- Yeni bir mühendisin de karmaşık bir kod tabanını keşfedebilmesini sağlayan tasarım iyi tasarım sayılırdı
- İyi tasarlanmış sistemlerde invariant'ların nerede olduğu, hangi parçaların load-bearing olduğu ve hangi değişikliklerin güvenli olduğu bilinen mühendisler vardı
- Büyük yazılımlar zaten tek bir insan zihnine sığmıyor ve dağıtık sistemler, doktorun semptomlara bakıp hipotez kurması ve daha fazla test istemesi gibi teşhis edilen bir yapıya sahip
- LLM'ler bu yönü daha da hızlandırıyor
- Üretim sorunu çıktığında makine log'ları okur
- Root cause önerir
- Patch gönderir
- Başka bir makine gözden geçirir ve bazen insan gözetimi olmadan
main'e alınır
- Bu yaklaşım güçlü ve çekici, ama insanlar sistemi eskisi gibi bütünüyle anlayamayabilir
- Onu yönetir, izler ve stabilize ederler ama mutlaka anlamazlar
- Her kodun insan eliyle yazılması gerekmez ve geçmişte daha kötü kodlar da yazılmış olabilir
Tamamen dışında kalması zor baskı
- Tamamen makine güdümlü bir gelecekte opt out etmek zor olabilir
- Güvenlik bunun en açık örneği
- Kişi kendi yazılımını döngülerle üretmese bile başkaları o yazılımın üzerinde döngü çalıştırır
- Saldırganlar makineleri sürekli çalıştırır
- Saldırgan olmasalar bile güvenlik araştırmacıları otomatikleştirilmiş işler yürütür
- Bunun sonucunda gerçek sorunlarla birlikte gürültü de gelir
- Daniel Stenberg'in curl ile ilgili summer of bliss yazısı, bakımcıların zaten maruz kaldığı baskıyı gösteriyor
- curl'ün çekirdek geliştirmesinde yapay zekanın büyük rol oynadığı görünmüyor
- Buna rağmen bakımcılar raporlarla eziliyor ve bunların çoğu yapay zeka üretimi raporlar
- Saldırganlar ve raporlayıcılar döngü çalıştırıyorsa savunmacıların da buna ayak uydurması gerekir
- Bu mutlaka doğrudan patch yazmak için olmayabilir
- Triage, yeniden üretim ve müdahale baskısı yüzünden makine kullanmak gerekebilir
- Rekabet baskısı da benzer
- Bazı ekipler salt hızla diğerlerinden daha fazlasını üretebilir
- Küçük bir grup makineleri iyi orkestre ederse proje aniden hızlanabilir
- Bazı startup'lar eskiden 50 kişinin gerektirdiği işi 5 kişiyle yapabilir
- Birileri ürün üzerinde döngü çalıştırıp “başka bir şeye benzetmesini” isteyebilir
- Her yazılım aynı ölçüde etkilenmez
- Bazı alanlar gevşekliği cezalandırır, güven ve sorumluluk ister
- Pek çok yazılımda hız, hızlı deney ve geniş kapsama çok önemlidir
Döngünün yarattığı yeni bağımlılık
- Döngülerin ürettiği araçlar, tek seferlik bir maliyetten ibaret değil; kalıcı bir bilişsel bağımlılık yaratabilir
- Geçmişte yazılım geliştirme derleyici gibi maliyetli araçlara bağlıydı, ama bugünün araçları sürekli erişilmesi gereken sistemlere daha yakın
- Eğer kod tabanı döngülerle üretiliyor, döngülerle inceleniyor, döngülerle yamalanıyor ve döngülerle korunuyorsa, aynı düzeyde sistem erişimi kesildiğinde sorun çıkabilir
- Ticaret kısıtlamaları yüzünden en güçlü modellere erişim kaybolabilir
- Maliyetler taşınamaz hâle gelebilir
- Ekip, makine olmadan kodu anlayabilen son yeteneğini yitirebilir
- İnsanlar için bakımının zor olmasının ötesinde, makine katılımını bakım modelinin bir parçası olarak varsayan kod tabanları ortaya çıkabilir
- Bunun bazı işaretleri şimdiden görülüyor
- Tam olarak açıklayamadığı kodu merge eden kişi sayısı artıyor
- Issue report'lar ya da sohbet tartışmaları, makinenin sağladığı bağlamla güçlendiriliyor veya yeniden yazılıyor
- Özetleme ve bağlamsallaştırmada makineye bağımlılık artıyor
- İnsanlar giderek daha sık LLM üzerinden konuşuyor
- Bunun mutlaka yanlış olduğu söylenemez ama önceki yaklaşıma göre büyük bir değişim
Bundan sonra gereken harness ve araçlar
- Daha fazla döngüyü yalnızca orkestre etmek yeterli değil
- Değişiklikleri, orkestrasyonu ve ajanları daha iyi görselleştirmek anlayışı otomatik olarak geri getirmez
- Gerekli yön iki seçenekten biri
- İnsanı yeniden çarpıcı biçimde döngünün içine çekmek ve döngünün yaptığı değişiklikleri uzun vadede okunabilir kılmak
- Giderek karmaşıklaşan sistemleri daha iyi birleştirme yolları bulmak
- Pi hakkındaki düşünceler de değişiyor
- Pi temkinliydi ve bu temkin iyi
- Her etkileşimin, takibi zor makine sürülerinin yaptığı değişikliklere dönüştüğü bir gelecek istenmiyor
- Pi'nin, kendi yazdığı yazılım yarışını kazanmak uğruna bakımı imkânsız bir kaosa dönüşmesi de istenmiyor
- Pi'nin bu tür mühendisliği teşvik etmesi de istenmiyor
- Yine de Pi bir harness ve harness'ler yeni deneylerin merkezinde
- Kodlama iş kuyrukları, ajan orkestrasyonu, subagent'lar ve durable session'lar giderek daha önemli olacak
- Döngüleri körü körüne benimsemeyenlerin bile denemeye başlaması gerekiyor
- Çünkü bu geleceği sınırlar içinde tutup katlanılabilir kılmanın yolunu anlamak gerekiyor
Döngüyü denetleme meselesi
- Harness döngüsü benimsendiğinde, işin ne zaman bittiğine harness karar verir
- Ajan döngüsünde model eninde sonunda “done” der ve insan gözden geçirir
- Ondan önce de genellikle insan araya girip yön verir
- İnsan süreçte yer alır ve bu süreçte öğrenir
- Harness'in işlettiği döngüde insanın rolü belirsizleşir
- “done” sinyali de anlamını yitirip başka bir makinenin değerlendireceği bir mesaja dönüşür
- İnsanın rolü bir tür haberciye yaklaşabilir
- Şu anda bu şekilde üretilen kodun önemli bir kısmı hoş gelmiyor ve yapay zeka destekli yazılımlarla etkileşim de keyif vermiyor
- Döngüler güçlü, ama sorumluluğu giderek ortadan kaldırıyor ve şimdilik insanı makineye boyun eğmeye teşvik eden bir yanı var
- Buna rağmen döngülerin geleceği geliyor gibi görünüyor
- Çok küçük ekiplerin imkânsız görünen hızlarda ürün çıkardığı örnekler şimdiden var
- Kod tabanları daha muğlak ve daha kaotik organizmalara dönüşüyor
- Bu tür kod tabanları aynı anda hem yararlı hem dağınık
- Bundan sonraki soru “döngü çalıştıracak mıyız?” değil, daha çok şuna yakın
- Döngü içinde muhakemeden nasıl vazgeçilmez
- İyi mühendislik kuralları nasıl korunur
- Sorumlu insanların gözetimi nasıl sürdürülür
- Aklı koruyabilmek için kod mimarisi nasıl yeniden düşünülür
1 yorum
Hacker News görüşleri
Loop, ne istediğinizi önceden yeterince iyi anlamak için zaman harcadığınızda işe yarıyor. Önkoşul netlik; yani bunu junior bir ekip arkadaşına devredebilecek kadar dikkatli bir spesifikasyon yazabiliyor olmanız gerekiyor
Genelde bunu anlayana kadar bozuk ve özensiz 5-6 sürümden geçmek gerekiyor. Bu 5-6 deneme-yanılma turu hızlandırılamıyor ve hiçbir ajan teknolojisi insan beyninin düşünmek için ihtiyaç duyduğu zamanı ortadan kaldıramıyor. Bu yüzden zamanın çoğu “ne istediğimi bilmiyorum, kodu okuyup yazıp kurcalamam lazım” ile “artık yeterince zaman geçti, sanırım ne istediğimi biliyorum” arasında gidip gelerek geçiyor. Kişinin kendini kandırması çok kolay ama gerçekten ne istediğinizi ancak ondan sonra anlıyorsunuz ve ancak o zaman Loop kullanılabiliyor. Birçok kişi ajanlarla bu aşamayı atlayabileceğini düşünüyor ama anlayış ve netlik taklit edilemez; bu adımı atlayan biri acı verecek kadar belli oluyor
Ne istediğim üzerine uzun uzun düşünmem gerekmedi, sadece onun bunu yapmasını istedim. Sonuçlar hâlâ karışık ve hassas bir kod tabanını emanet edecek kadar güvenmiyorum ama üzerinde çalıştığım oyunda doğrulama için harcadığım süre öncekinin 1/5'ine indi. Bu mutlaka iyi bir şey değil. Daha az zaman harcarken iyi fikirleri kaçırıyor olma ihtimalim yüksek. Ama daha önce prompt'lar mekanik olarak
#now-do-this,#now-review-thatdüzeyindeydi ve önerilerin %90'ı doğru olsa da orada tıkanıp kalıyordu. Şimdiyse önce “zor olanı yap, ilerlerken düzenle ve refactor et” diye, ilk dönüşten sonra da “yaptığın işi geriye dönük değerlendir” diye otomatik hatırlatıyor; böylece kalan sorunları dökmesini sağlıyor, sonra bunu rehber üretim prompt'una koyup yeni işler dağıtabiliyorumİterasyonlar hızlandı ama o özensiz sürümlerden geçmenin gerektirdiği çaba neredeyse aynı kaldı. Çünkü hâlâ hangi fikirlerin, ilkelerin ve tasarımların çözüme uyduğunu, sırada neyi denemek gerektiğini anlamam ve zihinsel modelimi ayarlamam gerekiyor. Sonuçta daha kısa sürede daha fazla zihinsel emek harcıyormuşum gibi geliyor; sadece kod yazımından biraz tasarruf ediyorum. Usta hale geldiğinizde kodu fiziksel olarak yazmak zaten baştan beri işin büyük kısmı değildi. “Sadece” prompt yazıp kod okuyormuş gibi görünse de aynı derecede yoruyor, hatta sıkışmış iterasyon döngüsü yüzünden bazen daha da fazla yoruyor
Artık bunu her gün yaşıyorum ve moral bozucu, hatta kaygı verici. Tam olarak açıklayamadığım daha fazla kodu merge etmemizin sebebinin, eskiden kod yazımı ve işbirlikçi teknik planlamayla kurduğumuz zihinsel modeli artık code review'a bırakmamız olduğunu düşünüyorum
Code review bu amaç için uygun değil. Yine de pedagojiden ilham alan yapılandırılmış alıştırmaları code review'a ekleyerek sürtünme ile anlayış arasındaki dengeyi daha iyi kurabileceğimizi düşünüyorum. Bu tür alıştırmaları test etmeme yardım edecek insanlar arıyorum
GitHub'ın zayıf PR arayüzü de yardımcı olmuyor. Doğrudan değişmemiş ama etkilenmiş olabilecek kod tabanı çevresini keşfedip sorunları bulmaya ve öne çıkarmaya yarayan araçlar sınırlı
Yanlış sınır koşullarını fallback ile ele almak yerine imkânsız hale getiren sistemleri tercih etmemiz gerektiğine dair asıl metindeki söz çok önemli. Fallback yaklaşımı, fallback üzerine bir fallback daha kurmaya zorluyor ve her fallback kod miktarını üstel olarak artırırken nedense hep yeni sorunlar yaratıyor. Buna neredeyse “sistem tasarımının genel yasası” denebilir. Fallback'ler başarısızlık riskini azaltıyor ama başarısızlık gerçekten olduğunda durumu daha karmaşık ve daha zararlı hale getiriyor. Bir yazılım mühendisi olarak AI'ın yarattığı yeni kodlama ortamını seviyorum. Çünkü Big Tech benim için sonsuz iş üretti. İnsan geliştirici, kodun çalıştırılmasının temel bir bileşeni haline geldi ve zaman zaman kaçınılmaz olarak ortaya çıkacak neredeyse sonsuz sayıdaki zor, ele alınmamış exception'ı çözmek için sürekli hazır beklemek zorunda. Artık yazılım mühendisi bir işçiden çok, çoğu zaman masasında oturup kahve içen, nadiren sorun çıktığında devreye giren bir güvenlik görevlisine benziyor
Bu, aylardır söylediğim şeyin devamı. LLM'ler iş tamamlama konusunda müthiş ama estetik anlayış ve zevk konusunda zayıf
İki tür iş var. Biri hedef odaklı iş; ulaşılması gereken bir hedef vardır ve oraya nasıl gidildiği çok da önemli değildir. Güvenlik bunun kusursuz örneği. Bir sistemi exploit etmek istiyorsanız, exploit'in güzel olup olmadığıyla neredeyse hiç ilgilenmezsiniz; tek istediğiniz çok gizli nükleer planlara erişmektir. Araştırma da benzer; “araştırma kalitesinde” kod, AI çağından önce de kötü olmasıyla meşhurdu. Diğeri ise zevk odaklı iş. Büyük bir kod tabanına özellik eklerken amacın o özelliği eklemek olduğunu sanırsınız ama çoğu zaman öyle değildir. Kod tabanını ilerideki değişiklikleri iyi karşılayacak halde tutmak, o belirli özellikten çok daha önemlidir ve bu da zevk gerektirir. Bakım yapılabilirlik ile kod kalitesi eşanlamlı değildir; kod kalitesi sadece bir araçtır, asıl amaç ise bakım yapılabilirliktir
LLM’lerin doğal biçimde hatalı olan durumları bile ele almaya çalışması, birçok PR incelemesinde mücadele ettiğimiz bir konu. Özellikle bir kez yazıldıktan sonra aşırı null kontrolünün zararlı olduğunu ikna edici biçimde anlatmak çok zor oluyor
Daha iyi modelleme ve birleşim tiplerine izin veren bir dil olmadıkça, bu tür “saçma sapan her şeyi parse etme” yaklaşımına karşı herkesçe geçerli bir itiraz henüz bulamadım. Belki de gerçekten çok büyük bir sorun değildir. Ama codebase’i gerçekten okuyup refactor ederken bu gereksiz kontrolleri yönetmek hep sinir bozucu oldu. Bir kere girdikten sonra, önce logging veya kapsamlı inceleme eklemeden bunları güvenle silmek neredeyse imkânsız olabiliyor
“İstenmeyen durumları ifade edilemez kılmak” denmesinin özü de tam olarak budur
Şu anda hiçbir şey bu fonksiyona negatif sayı göndermiyor olsa bile, gelecekteki bir kod değişikliğinin bu varsayımı bozması ne kadar zor olur? En iyisinin her zaman açık bir hata vermek olduğunu düşündüm. Böylece koda aşina olmayan biri bile girdinin geçerli aralığına dair hangi varsayımların olduğunu görebilir ve imkânsız uç durumları düşünmek zorunda kalmaz
Benim darboğazım spesifikasyon tarafında. Ajan döngüsü artık benim için daha az önemli bir mesele
Ne yapmak istediğime dair net bir anlayış edinip bunu Claude Code’un planlama modunda yürütülebilir bir spesifikasyon olarak yazma hedefini verirsem, ajan uygulamaya geçtiğinde genelde çok iyi sonuçlar çıkıyor. Ama etkili olan bu strateji, spesifikasyon yazma yükünü büyük ölçüde bana yüklüyor. Ajan her spesifikasyonu çoğunlukla çok iyi işliyor ve kod incelemesine dayalı takip işleri de genelde 2-3 turda tamamlanıyor, ama çok geçmeden yine spesifikasyon gereken aşamaya dönülüyor. Ayrıca ben uzaktayken ajan yaptığı işi bitirmiş ve dosyalar çakışmadığı için çatışma riski olmayan mevcut bir spesifikasyona başlayabilecek olsa bile, yeni bir branch oluşturup başlayabileceğini bilmiyor. Yatmadan önce sık sık “X işini yap, bitirip push ettikten sonra Y işine başla” diyorum ama bunun ötesi pek yürümüyor. Çoğu zaman Y’ye başlarken bir soru çıkıyor ve ardından ajan kalan zaman boyunca durmuş kalıyor. Son problem ise yukarıdakilerle birleşen bağımlılıklar. Mesela bugün arka plan işleyicisi yazdım; doğal olarak sonraki işlerdeki job’lar o sisteme ihtiyaç duyuyor. Bu oldukça sık oluyor. Uygulama sırasında verilen kararların ayrıntılarını yansıtmak için spesifikasyonların da uygulamadan sonra güncellenmesi gerekiyor. Yine de artık dış döngüye ihtiyaç duyulmadan hemen önceki noktadayız. Geçit neredeyse tamamen spesifikasyon yazımı ve PR incelemesinde. Bu geçidin önemli olmadığı yerlerde, ajanın çalışmaya devam etmesini istiyorum. Ayrıca, bize daha kötü gelse bile LLM’ler için daha iyi olan araçları kullanmaya başlamamız gerektiğine güçlü biçimde inanıyorum. Örneğin Rust, derleyicisi çok katı olduğu için bana sinir bozucu geliyor ama LLM’ler için harika
Artık inşa etme işi daha otomatik hâle geldiğine göre, spesifikasyon ve sistem tasarımı yeniden önemli öncü roller üstlenebilir. Belki mühendislik ve kalite geri döner
AI, teknik olarak çalışan fena olmayan çözümler üretmede çok iyi ama çözüme dair iyi bir vizyon geliştirmede oldukça zayıf. Fikir alışverişi yapıp keşfederek anlayışı derinleştirmede hâlâ çok faydalı, ama LLM’in uygulayabileceği iyi bir spesifikasyon yazmak, kodu doğrudan yazmaktan pek de daha kolay değil
https://www.aihero.dev/skills-handoff
/handoffbenim yeni favori becerimhttps://www.youtube.com/watch?v=dtAJ2dOd3ko
Ajanlar olsun ya da olmasın, delikli kartlar olsun ya da yorumlayıcılar, günün sonunda programlama yine programlamadır
LLM'lerin en büyük code smell'lerinden biri, “tüm yanlış durumları ele almaya” çalışmaları ve artık imkânsız hataları bile işlemeye uğraşmaları. Buna neden bu kadar takıntılı olduklarını bilmiyorum.
Python'da bu, tamamen type-check edilen bir kod tabanında, ilgili özelliğin bulunduğu tanımlı bir tipe
hasattrkontrolü eklemek gibi durumlarda sık görülüyor. Neden böyle yapıyorlar? Bunun ön eğitimden mi yoksa pekiştirmeli öğrenmeden mi kaynaklandığını merak ediyorum. İkincisiyse keşke laboratuvarlar bunu düzeltsaHN'de bu konu çok geçiyor ama ister açık kaynakta ister iş yerinde olsun, benim yazmadığım kod tabanlarının bunu gerçekten iyi yaptığını gördüğümde hâlâ şaşırıyorum. Programcıların çoğu, hataların hiç oluşmamasını sağlayıp veriyi de buna göre yansıtmak yerine, hata mesajının fırladığı noktada parçaları toplayıp düzeltmek şeklinde düşünüyor. “Çoğu” diyorum çünkü mevcut AI'da da bu düşünme biçiminin kendisinde bir sorun olduğunu düşünüyorum. İnsanların bir kod tabanını son aşamada anlama seviyesi, yani garantilerin akışını bütünsel olarak kavrama seviyesi, şu an AI'ya verilmesi zor bir şey. Ham kod düzeyinde bu garantiler çoğu zaman context window'u rahatça taşıracak kadar çok koda yayılıyor. Bellek benzeri dosyalarla özetlemeye çalışmanın da sorunları var. Garantiler hakkında metin yazıyor olması, AI'nın doğru bilgiyi çekip çıkaracağı anlamına gelmiyor; insanlar için de sadece kodu okuyarak durum aynı. AI'ya bu tür bir anlayış kazandırmanın “imkânsız” olduğunu söylemem ama bunu başarsanız bile AI'nın çalışma biçimi çoğu zaman bu anlayışa ters yönde işliyor. Benim çözümüm genelde AI'nın bunu anlamasını beklemekten vazgeçmek oldu. Genelde insanların yaptığı gibi, problem çözümünü prompt'a dönüştürüyorum; kötü yanlış durumları ifade edilemez kılmak istiyorsam gerekli refactoring sürecini AI'ya adım adım yaptırıyorum. Çok küçükse kendim yapıyorum. Map/dictionary, array, string ve integer dolu kodu daha sıkı typed hâle getirmesini aşamalı olarak söylediğinizde aslında epey iyi iş çıkarıyor. Ne kadar ayrıntılı yazarsam yazayım, tek bir prompt'tan iyi bir tasarım çıktığı çok sık olmadı. Bunu iki ayrı iş olarak ele almak daha iyi uyuyor. Ayrıca type farklarına dikkatle bakmak gerekiyor. AI,
.JustSetItAndIgnoreAllThePreAndPostConditions(string)gibi metodları gizlice araya sıkıştırmayı seviyor. Sahada, “hata durumlarını ifade edilemez kılacak şekilde iyi yapılandırılmış type'lara sonradan bir bakımcı gelip her şeyi bozanJustEffingDoItmetodunu eklediği” çok fazla eğitim verisi olduğunu tahmin ediyorum. En iyi savunmalardan biri, bu tür type'ları ayrı dosyalarda tutup eklenen tüm metodları kolayca gözden geçirmek ve böyle bir şey olursa anında düzeltmek. Belgelerde yapılmaması gerektiğine dair uyarıları ve korunan pre/post-condition'ları bolca yazdım ama değişim çok az oldugetattrkullanmak tuhaf bir tercihKod, bir bilgi sistemi hakkında paylaşılan ve zamanla biriken anlayışın bir parçasıdır
Eğer bu döngüler, sürekli üzerimize gelen yazılım dalgası içinde hepimizi hareket etmeye zorluyorsa, o zaman en üst düzey mantıksal bilgi sistemi tasarımında sonuçta her şey insan yargısına ve iş gereksinimlerini dengeleme becerisine dayanıyor demektir. Bir şirketin ya da pazarın belirli bir nişine uyum sağlamak için her programcının bir iş analisti, pazar araştırmacısı ve girişimci olması gerekir. Tabii AI araçlarının iyi “takırdayamadığı” belirli nişler ya da sübvansiyonlu AI token çağı bitip de tüm bu döngülerin fazla pahalı hâle gelmesi gibi istisnalar dışında. Bu bana uzman sistemlerin ve Symbolics Lisp makinelerinin tekrarını hatırlatıyor. Kısa bir süreliğine karşılaştığımız gerçek şu oldu: kodun kendisinin bir şeyi yapamamasından çok, şirketin organizasyon yapısının eninde sonunda yazılıma aynen yansıması ve dolayısıyla şirket organizasyonunu değiştiremiyorsanız yazılımın esnekliğinin de bir sınırı olması. Veri akış diyagramları, alan bilgisi, domain modeling ve ubiquitous language; kaliteyi, işlevi, işlevsel olmayan standartları ve teamülleri tanımladığımız meta dil olabilir. “Döngüde gezen clanker”ların “tamamlandı” demeden önce veri/davranış/performance sözleşmelerini karşılamasını sağlamalıyız. Artık “tamamlandı” yalnızca derlenen kod, build alan kod, deploy edilen kod, hatta production'a çıkan kod anlamına gelmiyor. Kullanıcı gereksinimlerini, operatör gereksinimlerini ve bakımcı gereksinimlerini de karşılayan kod anlamına geliyor. Bu yüzden kullandığımız dil, hepimizi sadece sözdizimini bilen kişiler olmaktan çıkarıp iş analistleri ve yazılım mimarlarına daha yakın hâle getirebilir. Bu, UML'in intikamı ve deklaratif/mantıksal tasarım ile BDD'nin geri dönüşü mü?
Yazım denetimini gemma4-12b ile yaptım ama mesajı değiştirmesine izin vermedim
Ne zamandan itibaren döngünün içine zorla girmem gerekmeyeceğini sürekli düşünüyorum. Geliştirici olarak kod yapısını cilalamayı, onu daha açık hâle getirmeyi, iyi soyutlamalar düşünmeyi ve modüllere ayırmayı gerçekten seviyorum
Bundan keyif alıyorum ama bir noktada sınırlayıcı etkenin ben olduğumu da anlıyorum. Yazılımın amacı insanlara fayda sağlamaksa, kodun nasıl göründüğünü hâlâ önemsemeli miyim? Şimdilik cevabın “evet” olduğunu düşünüyorum ama 3 yıl sonra? 10 yıl sonra?
Eğer bir şey çok fazla muhakeme gerektiriyorsa ve “derinden önemsediğim bir kod” ise, burada anlatılan yöne katılmak zor. Derinden önem verdiğin kararları devretmeye çalışmamalısın
Ajan döngüsü ile harness döngüsü arasındaki ayrımı beğeniyorum ama yalnızca önceden kesin biçimde tanımlayabildiğin şeyleri devretmelisin. Benim durumumda bu genelde tekrarlanabilir işler oluyor; örneğin “X’in nasıl yapıldığına bak ve Y’de de öyle yap” gibi şeyler, ki bunlar özünde öngörülebilir işler. Benim muhakemem devreden çıkınca sonunda benim “hayır” diyeceğim bir şey olacaksa, Armin’in sözünü ettiği ajan döngüsü içinde işbirliği tarafına geri dönmek gerekir. Bu tamamen sorun değil. Hem hızlı hem güvenli. Yapay zeka kodlama yardımcılarından önce de ara sıra inanılmaz üretken mühendisler takıma katılırdı. Ekip arkadaşları “Bunu başarmanızın sebebi takımda X’in olması!” diye imrenirdi ama böyle birini yanında bulundurmanın lanetini yaşamamış olurlardı. Mükemmel biçimde hizalanmamışlarsa, korkunç bir hızla yanlış yöne koşarlar
Bunun pratikte ne anlama geldiğini bilmiyorum. Daha büyük bir resmi ima etmek için tasarlanmış gibi duran soyut kavramların sıralandığı, lafı uzatan bir yazı sadece; sonuçta konu yine AI'ın kod yazması
Bundan sonra böyle mi olacak? Aslında düşünce lideri değiliz de, AI aptallar sürüsünü doğru cevaba doğru gütmeye çalışan sahte öğretmenlere mi dönüşüyoruz; ama yine de düşünce lideri gibi görünmek için rolümüzü gizemli hale getirmemiz mi gerekiyor? Üstelik bunun tamamen teknolojik gösteriş olduğu ortaya çıkmadan?
Yazar bunu daha kısa ve derli toplu hale getirebilirdi ama mevcut haliyle bir okurun anlamaması, ortada bir gizemlileştirme olduğu anlamına gelmez
İşte ve kişisel projelerimde, özgün metnin anlattığı şeyi birebir görüyorum; birinin bunu “soyut kavramların sıralandığı, lafı uzatan bir yazı” olarak görmesi bana ürkütücü geliyor. Çoğu insanın şu an olan bitenden tamamen habersiz olduğu hissine kapılıyorum
AI alanında en yeni en iyi tekniğin raf ömrü yaklaşık 2 hafta. Ralph Wiggum döngüsünü yakalayamamıştım, şimdi de iyi ki denememişim gibi geliyor
https://news.ycombinator.com/item?id=46682325